commit 52f863f820fd540a98596d0dc33ae5cb524fa1e9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Dec 14 19:54:56 2024 +0100

    Linux 6.1.120
    
    Link: https://lore.kernel.org/r/20241212144349.797589255@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: SeongJae Park <sj@kernel.org>
    Link: https://lore.kernel.org/r/20241213150009.122200534@linuxfoundation.org
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Sven Joachim <svenjoac@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3f594a3473d6429a0bcf2004cb2885368741b79
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Nov 21 11:09:22 2024 -0500

    Bluetooth: MGMT: Fix possible deadlocks
    
    commit a66dfaf18fd61bb75ef8cee83db46b2aadf153d0 upstream.
    
    This fixes possible deadlocks like the following caused by
    hci_cmd_sync_dequeue causing the destroy function to run:
    
     INFO: task kworker/u19:0:143 blocked for more than 120 seconds.
           Tainted: G        W  O        6.8.0-2024-03-19-intel-next-iLS-24ww14 #1
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     task:kworker/u19:0   state:D stack:0     pid:143   tgid:143   ppid:2      flags:0x00004000
     Workqueue: hci0 hci_cmd_sync_work [bluetooth]
     Call Trace:
      <TASK>
      __schedule+0x374/0xaf0
      schedule+0x3c/0xf0
      schedule_preempt_disabled+0x1c/0x30
      __mutex_lock.constprop.0+0x3ef/0x7a0
      __mutex_lock_slowpath+0x13/0x20
      mutex_lock+0x3c/0x50
      mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]
      ? kfree+0x211/0x2a0
      hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]
      ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]
      cmd_complete_rsp+0x26/0x80 [bluetooth]
      mgmt_pending_foreach+0x4d/0x70 [bluetooth]
      __mgmt_power_off+0x8d/0x180 [bluetooth]
      ? _raw_spin_unlock_irq+0x23/0x40
      hci_dev_close_sync+0x445/0x5b0 [bluetooth]
      hci_set_powered_sync+0x149/0x250 [bluetooth]
      set_powered_sync+0x24/0x60 [bluetooth]
      hci_cmd_sync_work+0x90/0x150 [bluetooth]
      process_one_work+0x13e/0x300
      worker_thread+0x2f7/0x420
      ? __pfx_worker_thread+0x10/0x10
      kthread+0x107/0x140
      ? __pfx_kthread+0x10/0x10
      ret_from_fork+0x3d/0x60
      ? __pfx_kthread+0x10/0x10
      ret_from_fork_asm+0x1b/0x30
      </TASK>
    
    Tested-by: Kiran K <kiran.k@intel.com>
    Fixes: f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56bddf543d4d7ddeff3f87b554ddacfdf086bffe
Author: Kaixin Wang <kxwang23@m.fudan.edu.cn>
Date:   Sun Sep 15 00:39:33 2024 +0800

    i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition
    
    commit 61850725779709369c7e907ae8c7c75dc7cec4f3 upstream.
    
    In the svc_i3c_master_probe function, &master->hj_work is bound with
    svc_i3c_master_hj_work, &master->ibi_work is bound with
    svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work  can start the
    hj_work, svc_i3c_master_irq_handler can start the ibi_work.
    
    If we remove the module which will call svc_i3c_master_remove to
    make cleanup, it will free master->base through i3c_master_unregister
    while the work mentioned above will be used. The sequence of operations
    that may lead to a UAF bug is as follows:
    
    CPU0                                         CPU1
    
                                        | svc_i3c_master_hj_work
    svc_i3c_master_remove               |
    i3c_master_unregister(&master->base)|
    device_unregister(&master->dev)     |
    device_release                      |
    //free master->base                 |
                                        | i3c_master_do_daa(&master->base)
                                        | //use master->base
    
    Fix it by ensuring that the work is canceled before proceeding with the
    cleanup in svc_i3c_master_remove.
    
    Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kaixin Wang <kxwang23@m.fudan.edu.cn>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/stable/20240914154030.180-1-kxwang23%40m.fudan.edu.cn
    Link: https://lore.kernel.org/r/20240914163932.253-1-kxwang23@m.fudan.edu.cn
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec062a450cfad5178cf94c4664a3a979778faa59
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu Sep 5 15:03:48 2024 +0300

    fs/ntfs3: Sequential field availability check in mi_enum_attr()
    
    commit 090f612756a9720ec18b0b130e28be49839d7cb5 upstream.
    
    The code is slightly reformatted to consistently check field availability
    without duplication.
    
    Fixes: 556bdf27c2dd ("ntfs3: Add bounds checking to mi_enum_attr()")
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 746ed28a968e8faad049ada24a2de00b3253f6a1
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Feb 19 17:04:28 2023 -0800

    drm/msm: DEVFREQ_GOV_SIMPLE_ONDEMAND is no longer needed
    
    commit a722511b18268bd1f7084eee243af416b85f288f upstream.
    
    DRM_MSM no longer needs DEVFREQ_GOV_SIMPLE_ONDEMAND (since commit
    dbd7a2a941b8 ("PM / devfreq: Fix build issues with devfreq disabled")
    in linux-next), so remove that select from the DRM_MSM Kconfig file.
    
    Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Cc: Sean Paul <sean@poorly.run>
    Cc: David Airlie <airlied@gmail.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: linux-arm-msm@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: freedreno@lists.freedesktop.org
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Patchwork: https://patchwork.freedesktop.org/patch/523353/
    Link: https://lore.kernel.org/r/20230220010428.16910-1-rdunlap@infradead.org
    [rob: tweak commit message to make checkpatch.pl happy]
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5446585e424248859fcf936a354278d1f6f95038
Author: Rob Clark <robdclark@chromium.org>
Date:   Mon Jan 23 07:37:45 2023 -0800

    PM / devfreq: Fix build issues with devfreq disabled
    
    commit dbd7a2a941b8cbf9e5f79a777ed9fe0090eebb61 upstream.
    
    The existing no-op shims for when PM_DEVFREQ (or an individual governor)
    only do half the job.  The governor specific config/tuning structs need
    to be available to avoid compile errors in drivers using devfreq.
    
    Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
    Patchwork: https://patchwork.freedesktop.org/patch/519801/
    Link: https://lore.kernel.org/r/20230123153745.3185032-1-robdclark@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a08c1f1268297b1e7305411428d7a688e2d4d3ad
Author: Frank Li <Frank.Li@nxp.com>
Date:   Wed Oct 2 10:50:38 2024 -0400

    i3c: master: svc: fix possible assignment of the same address to two devices
    
    commit 3b2ac810d86eb96e882db80a3320a3848b133208 upstream.
    
    svc_i3c_master_do_daa() {
        ...
        for (i = 0; i < dev_nb; i++) {
            ret = i3c_master_add_i3c_dev_locked(m, addrs[i]);
            if (ret)
                goto rpm_out;
        }
    }
    
    If two devices (A and B) are detected in DAA and address 0xa is assigned to
    device A and 0xb to device B, a failure in i3c_master_add_i3c_dev_locked()
    for device A (addr: 0xa) could prevent device B (addr: 0xb) from being
    registered on the bus. The I3C stack might still consider 0xb a free
    address. If a subsequent Hotjoin occurs, 0xb might be assigned to Device A,
    causing both devices A and B to use the same address 0xb, violating the I3C
    specification.
    
    The return value for i3c_master_add_i3c_dev_locked() should not be checked
    because subsequent steps will scan the entire I3C bus, independent of
    whether i3c_master_add_i3c_dev_locked() returns success.
    
    If device A registration fails, there is still a chance to register device
    B. i3c_master_add_i3c_dev_locked() can reset DAA if a failure occurs while
    retrieving device information.
    
    Cc: stable@kernel.org
    Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry")
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241002-svc-i3c-hj-v6-6-7e6e1d3569ae@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9645cf5e0373f34621bd775d82df033437f6423
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Oct 1 12:22:32 2024 -0400

    i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin
    
    commit 36faa04ce3d9c962b4b29d285ad07ca29e2988e4 upstream.
    
    When a new device hotjoins, a new dynamic address is assigned.
    i3c_master_add_i3c_dev_locked() identifies that the device was previously
    attached to the bus and locates the olddev.
    
    i3c_master_add_i3c_dev_locked()
    {
        ...
        olddev = i3c_master_search_i3c_dev_duplicate(newdev);
        ...
        if (olddev) {
            ...
            i3c_dev_disable_ibi_locked(olddev);
            ^^^^^^
            The olddev should not receive any commands on the i3c bus as it
            does not exist and has been assigned a new address. This will
            result in NACK or timeout. So remove it.
        }
    
        i3c_dev_free_ibi_locked(olddev);
        ^^^^^^^^
        This function internally calls i3c_dev_disable_ibi_locked() function
        causing to send DISEC command with old Address.
    
        The olddev should not receive any commands on the i3c bus as it
        does not exist and has been assigned a new address. This will
        result in NACK or timeout. So, update the olddev->ibi->enabled
        flag to false to avoid DISEC with OldAddr.
    }
    
    Include part of Ravindra Yashvant Shinde's work:
    https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u
    
    Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry")
    Co-developed-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com>
    Signed-off-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f5c20b9fafd0fafe8ef5a593722d096e5bc381b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 15 11:59:54 2024 +0100

    serial: amba-pl011: fix build regression
    
    commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream.
    
    When CONFIG_DMA_ENGINE is disabled, the driver now fails to build:
    
    drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx':
    drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma'
     1822 |         if (uap->using_rx_dma) {
          |                ^~
    drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr'
     1823 |                 uap->dmacr |= UART011_RXDMAE;
          |                    ^~
    drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr'
     1824 |                 pl011_write(uap->dmacr, uap, REG_DMACR);
          |                                ^~
    
    Add the missing #ifdef check around these field accesses, matching
    what other parts of this driver do.
    
    Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used")
    Cc: stable <stable@kernel.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cb99eeb1d318dcf03b3de87fc75ecae91ad6735
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Tue Apr 16 01:23:07 2024 +0000

    usb: dwc3: ep0: Don't reset resource alloc flag
    
    commit f2e0eee4703869dc5edb5302a919861566ca7797 upstream.
    
    The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an
    endpoint is only assigned once. Unless the endpoint is reset, don't
    clear this flag. Otherwise we may set endpoint resource again, which
    prevents the driver from initiate transfer after handling a STALL or
    endpoint halt to the control endpoint.
    
    Cc: stable@vger.kernel.org
    Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/00122b7cc5be06abef461776e7cc9f5ebc8bc1cb.1713229786.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c807ab3a861f656bc39471a20a16b36632ac6b04
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 25 13:59:09 2024 -0500

    drm/amdgpu: rework resume handling for display (v2)
    
    commit 73dae652dcac776296890da215ee7dec357a1032 upstream.
    
    Split resume into a 3rd step to handle displays when DCC is
    enabled on DCN 4.0.1.  Move display after the buffer funcs
    have been re-enabled so that the GPU will do the move and
    properly set the DCC metadata for DCN.
    
    v2: fix fence irq resume ordering
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.11.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77ab79b9e4f351b182dbd4670bee7a28a1140a08
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Mon Dec 9 09:49:04 2024 +0000

    drm/ttm: Print the memory decryption status just once
    
    commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.
    
    Stop printing the TT memory decryption status info each time tt is created
    and instead print it just once.
    
    Reduces the spam in the system logs when running guests with SEV enabled.
    
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when needed")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: linux-kernel@vger.kernel.org
    Cc: <stable@vger.kernel.org> # v5.14+
    Link: https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.rusin@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ye Li <ye.li@broadcom.com>
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef7efa60a38d43050db7b5e62d554e432de39fc4
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Mon Dec 9 09:49:03 2024 +0000

    drm/ttm: Make sure the mapped tt pages are decrypted when needed
    
    commit 71ce046327cfd3aef3f93d1c44e091395eb03f8f upstream.
    
    Some drivers require the mapped tt pages to be decrypted. In an ideal
    world this would have been handled by the dma layer, but the TTM page
    fault handling would have to be rewritten to able to do that.
    
    A side-effect of the TTM page fault handling is using a dma allocation
    per order (via ttm_pool_alloc_page) which makes it impossible to just
    trivially use dma_mmap_attrs. As a result ttm has to be very careful
    about trying to make its pgprot for the mapped tt pages match what
    the dma layer thinks it is. At the ttm layer it's possible to
    deduce the requirement to have tt pages decrypted by checking
    whether coherent dma allocations have been requested and the system
    is running with confidential computing technologies.
    
    This approach isn't ideal but keeping TTM matching DMAs expectations
    for the page properties is in general fragile, unfortunately proper
    fix would require a rewrite of TTM's page fault handling.
    
    Fixes vmwgfx with SEV enabled.
    
    v2: Explicitly include cc_platform.h
    v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
    limit the scope to guests and log when memory decryption is enabled.
    
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
    Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: linux-kernel@vger.kernel.org
    Cc: <stable@vger.kernel.org> # v5.14+
    Link: https://patchwork.freedesktop.org/patch/msgid/20230926040359.3040017-1-zack@kde.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Ye Li <ye.li@broadcom.com>
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ca7b6649bf0702fe1c8591e5ea64e51febbdd3c
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Fri Dec 6 16:34:03 2024 +0100

    veth: Use tstats per-CPU traffic counters
    
    [ Upstream commit 6f2684bf2b4460c84d0d34612a939f78b96b03fc ]
    
    Currently veth devices use the lstats per-CPU traffic counters, which only
    cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
    device from its peer's TX counters, based on the assumption that a veth
    device can _only_ receive packets from its peer, which is no longer true:
    
    For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
    helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
    a different netns), skipping veth's peer device. Unfortunately, this kind
    of traffic isn't currently accounted for in veth's RX stats.
    
    In preparation for the fix, use tstats (instead of lstats) to maintain
    both RX and TX counters for each veth device. We'll use RX counters for
    bpf_redirect_peer() traffic, and keep using TX counters for the usual
    "peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
    _adding_ RX count to peer's TX count, in order to cover both kinds of
    traffic.
    
    veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
    for less confusion, but let's leave it to another patch to keep the fix
    minimal.
    
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e7b5300a0ee6fa93062182de7b331271d94a2fc
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Fri Dec 6 16:34:02 2024 +0100

    bpf: Fix dev's rx stats for bpf_redirect_peer traffic
    
    [ Upstream commit 024ee930cb3c9ae49e4266aee89cfde0ebb407e1 ]
    
    Traffic redirected by bpf_redirect_peer() (used by recent CNIs like Cilium)
    is not accounted for in the RX stats of supported devices (that is, veth
    and netkit), confusing user space metrics collectors such as cAdvisor [0],
    as reported by Youlun.
    
    Fix it by calling dev_sw_netstats_rx_add() in skb_do_redirect(), to update
    RX traffic counters. Devices that support ndo_get_peer_dev _must_ use the
    @tstats per-CPU counters (instead of @lstats, or @dstats).
    
    To make this more fool-proof, error out when ndo_get_peer_dev is set but
    @tstats are not selected.
    
      [0] Specifically, the "container_network_receive_{byte,packet}s_total"
          counters are affected.
    
    Fixes: 9aa1206e8f48 ("bpf: Add redirect_peer helper")
    Reported-by: Youlun Zhang <zhangyoulun@bytedance.com>
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20231114004220.6495-6-daniel@iogearbox.net
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 877c81faf00548720a7f436538865070a5d63c96
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Dec 6 16:34:01 2024 +0100

    net: Move {l,t,d}stats allocation to core and convert veth & vrf
    
    [ Upstream commit 34d21de99cea9cb17967874313e5b0262527833c ]
    
    Move {l,t,d}stats allocation to the core and let netdevs pick the stats
    type they need. That way the driver doesn't have to bother with error
    handling (allocation failure checking, making sure free happens in the
    right spot, etc) - all happening in the core.
    
    Co-developed-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Cc: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20231114004220.6495-3-daniel@iogearbox.net
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Stable-dep-of: 024ee930cb3c ("bpf: Fix dev's rx stats for bpf_redirect_peer traffic")
    [ Note: Simplified vrf bits to reduce patch given unrelated to the fix ]
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Sep 13 21:17:48 2024 +0200

    bpf: Fix helper writes to read-only maps
    
    commit 32556ce93bc45c730829083cb60f95a2728ea48b upstream.
    
    Lonial found an issue that despite user- and BPF-side frozen BPF map
    (like in case of .rodata), it was still possible to write into it from
    a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
    as arguments.
    
    In check_func_arg() when the argument is as mentioned, the meta->raw_mode
    is never set. Later, check_helper_mem_access(), under the case of
    PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
    subsequent call to check_map_access_type() and given the BPF map is
    read-only it succeeds.
    
    The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
    when results are written into them as opposed to read out of them. The
    latter indicates that it's okay to pass a pointer to uninitialized memory
    as the memory is written to anyway.
    
    However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
    just with additional alignment requirement. So it is better to just get
    rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
    fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
    alignment given these helpers write directly into the args via *<ptr> = val.
    The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).
    
    MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
    argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
    the buffer size a priori and therefore cannot blindly write *<ptr> = val.
    
    Fixes: 57c3bb725a3d ("bpf: Introduce ARG_PTR_TO_{INT,LONG} arg types")
    Reported-by: Lonial Con <kongln9170@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
    Link: https://lore.kernel.org/r/20240913191754.13290-3-daniel@iogearbox.net
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    [ Resolve merge conflict in include/linux/bpf.h and merge conflict in
      kernel/bpf/verifier.c.]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1
Author: Shu Han <ebpqwerty472123@gmail.com>
Date:   Tue Sep 17 17:41:04 2024 +0800

    mm: call the security_mmap_file() LSM hook in remap_file_pages()
    
    commit ea7e2d5e49c05e5db1922387b09ca74aa40f46e2 upstream.
    
    The remap_file_pages syscall handler calls do_mmap() directly, which
    doesn't contain the LSM security check. And if the process has called
    personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
    RW pages, this will actually result in remapping the pages to RWX,
    bypassing a W^X policy enforced by SELinux.
    
    So we should check prot by security_mmap_file LSM hook in the
    remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
    potentially permits an attacker to bypass a W^X policy enforced by
    SELinux.
    
    The bypass is similar to CVE-2016-10044, which bypass the same thing via
    AIO and can be found in [1].
    
    The PoC:
    
    $ cat > test.c
    
    int main(void) {
            size_t pagesz = sysconf(_SC_PAGE_SIZE);
            int mfd = syscall(SYS_memfd_create, "test", 0);
            const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
                    MAP_SHARED, mfd, 0);
            unsigned int old = syscall(SYS_personality, 0xffffffff);
            syscall(SYS_personality, READ_IMPLIES_EXEC | old);
            syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
            syscall(SYS_personality, old);
            // show the RWX page exists even if W^X policy is enforced
            int fd = open("/proc/self/maps", O_RDONLY);
            unsigned char buf2[1024];
            while (1) {
                    int ret = read(fd, buf2, 1024);
                    if (ret <= 0) break;
                    write(1, buf2, ret);
            }
            close(fd);
    }
    
    $ gcc test.c -o test
    $ ./test | grep rwx
    7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)
    
    Link: https://project-zero.issues.chromium.org/issues/42452389 [1]
    Cc: stable@vger.kernel.org
    Signed-off-by: Shu Han <ebpqwerty472123@gmail.com>
    Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    [PM: subject line tweaks]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    [ Resolve merge conflict in mm/mmap.c. ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c38ab25aac8d3558ee6c7f35bcb66c881244127
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date:   Thu Oct 10 13:20:08 2024 +0200

    ASoC: Intel: avs: Fix return status of avs_pcm_hw_constraints_init()
    
    commit a0aae96be5ffc5b456ca07bfe1385b721c20e184 upstream.
    
    Check for return code from avs_pcm_hw_constraints_init() in
    avs_dai_fe_startup() only checks if value is different from 0. Currently
    function can return positive value, change it to return 0 on success.
    
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    I've observed KASAN on our setups and while patch itself is correct
    regardless. Problem seems to be caused by recent changes to rates, as
    this started happening after recent patchsets and doesn't reproduce with
    those reverted
    https://lore.kernel.org/linux-sound/20240905-alsa-12-24-128-v1-0-8371948d3921@baylibre.com/
    https://lore.kernel.org/linux-sound/20240911135756.24434-1-tiwai@suse.de/
    I've tested using Mark tree, where they are both applied and for some
    reason snd_pcm_hw_constraint_minmax() started returning positive value,
    while previously it returned 0. I'm bit worried if it signals some
    potential deeper problem regarding constraints with above changes.
    
    Link: https://patch.msgid.link/20241010112008.545526-1-amadeuszx.slawinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfcaffd4cc2d61ecb0571c5baf127c4089978ad4
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Nov 6 16:04:48 2024 +0000

    arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint
    
    commit 8c462d56487e3abdbf8a61cedfe7c795a54f4a78 upstream.
    
    SMCCCv1.3 added a hint bit which callers can set in an SMCCC function ID
    (AKA "FID") to indicate that it is acceptable for the SMCCC
    implementation to discard SVE and/or SME state over a specific SMCCC
    call. The kernel support for using this hint is broken and SMCCC calls
    may clobber the SVE and/or SME state of arbitrary tasks, though FPSIMD
    state is unaffected.
    
    The kernel support is intended to use the hint when there is no SVE or
    SME state to save, and to do this it checks whether TIF_FOREIGN_FPSTATE
    is set or TIF_SVE is clear in assembly code:
    
    |        ldr     <flags>, [<current_task>, #TSK_TI_FLAGS]
    |        tbnz    <flags>, #TIF_FOREIGN_FPSTATE, 1f   // Any live FP state?
    |        tbnz    <flags>, #TIF_SVE, 2f               // Does that state include SVE?
    |
    | 1:     orr     <fid>, <fid>, ARM_SMCCC_1_3_SVE_HINT
    | 2:
    |        << SMCCC call using FID >>
    
    This is not safe as-is:
    
    (1) SMCCC calls can be made in a preemptible context and preemption can
        result in TIF_FOREIGN_FPSTATE being set or cleared at arbitrary
        points in time. Thus checking for TIF_FOREIGN_FPSTATE provides no
        guarantee.
    
    (2) TIF_FOREIGN_FPSTATE only indicates that the live FP/SVE/SME state in
        the CPU does not belong to the current task, and does not indicate
        that clobbering this state is acceptable.
    
        When the live CPU state is clobbered it is necessary to update
        fpsimd_last_state.st to ensure that a subsequent context switch will
        reload FP/SVE/SME state from memory rather than consuming the
        clobbered state. This and the SMCCC call itself must happen in a
        critical section with preemption disabled to avoid races.
    
    (3) Live SVE/SME state can exist with TIF_SVE clear (e.g. with only
        TIF_SME set), and checking TIF_SVE alone is insufficient.
    
    Remove the broken support for the SMCCCv1.3 SVE saving hint. This is
    effectively a revert of commits:
    
    * cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint")
    * a7c3acca5380 ("arm64: smccc: Save lr before calling __arm_smccc_sve_check()")
    
    ... leaving behind the ARM_SMCCC_VERSION_1_3 and ARM_SMCCC_1_3_SVE_HINT
    definitions, since these are simply definitions from the SMCCC
    specification, and the latter is used in KVM via ARM_SMCCC_CALL_HINTS.
    
    If we want to bring this back in future, we'll probably want to handle
    this logic in C where we can use all the usual FPSIMD/SVE/SME helper
    functions, and that'll likely require some rework of the SMCCC code
    and/or its callers.
    
    Fixes: cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint")
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20241106160448.2712997-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    [ Mark: fix conflicts in <linux/arm-smccc.h> ]
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de529504b3274d57caf8f66800b714b0d3ee235a
Author: Mark Brown <broonie@kernel.org>
Date:   Wed Oct 30 20:23:50 2024 +0000

    arm64/sve: Discard stale CPU state when handling SVE traps
    
    commit 751ecf6afd6568adc98f2a6052315552c0483d18 upstream.
    
    The logic for handling SVE traps manipulates saved FPSIMD/SVE state
    incorrectly, and a race with preemption can result in a task having
    TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
    is stale (e.g. with SVE traps enabled). This has been observed to result
    in warnings from do_sve_acc() where SVE traps are not expected while
    TIF_SVE is set:
    
    |         if (test_and_set_thread_flag(TIF_SVE))
    |                 WARN_ON(1); /* SVE access shouldn't have trapped */
    
    Warnings of this form have been reported intermittently, e.g.
    
      https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/
      https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/
    
    The race can occur when the SVE trap handler is preempted before and
    after manipulating the saved FPSIMD/SVE state, starting and ending on
    the same CPU, e.g.
    
    | void do_sve_acc(unsigned long esr, struct pt_regs *regs)
    | {
    |         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
    |         // task->fpsimd_cpu is 0.
    |         // per_cpu_ptr(&fpsimd_last_state, 0) is task.
    |
    |         ...
    |
    |         // Preempted; migrated from CPU 0 to CPU 1.
    |         // TIF_FOREIGN_FPSTATE is set.
    |
    |         get_cpu_fpsimd_context();
    |
    |         if (test_and_set_thread_flag(TIF_SVE))
    |                 WARN_ON(1); /* SVE access shouldn't have trapped */
    |
    |         sve_init_regs() {
    |                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
    |                         ...
    |                 } else {
    |                         fpsimd_to_sve(current);
    |                         current->thread.fp_type = FP_STATE_SVE;
    |                 }
    |         }
    |
    |         put_cpu_fpsimd_context();
    |
    |         // Preempted; migrated from CPU 1 to CPU 0.
    |         // task->fpsimd_cpu is still 0
    |         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
    |         // - Stale HW state is reused (with SVE traps enabled)
    |         // - TIF_FOREIGN_FPSTATE is cleared
    |         // - A return to userspace skips HW state restore
    | }
    
    Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
    by calling fpsimd_flush_task_state() to detach from the saved CPU
    state. This ensures that a subsequent context switch will not reuse the
    stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
    new state to be reloaded from memory prior to a return to userspace.
    
    Fixes: cccb78ce89c4 ("arm64/sve: Rework SVE access trap to convert state in registers")
    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20241030-arm64-fpsimd-foreign-flush-v1-1-bd7bd66905a2@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d687b98747eb016d26f6504db401eb9d18c241e
Author: Ziwei Xiao <ziweixiao@google.com>
Date:   Mon Nov 13 16:41:44 2023 -0800

    gve: Fixes for napi_poll when budget is 0
    
    commit 278a370c1766060d2144d6cf0b06c101e1043b6d upstream.
    
    Netpoll will explicilty pass the polling call with a budget of 0 to
    indicate it's clearing the Tx path only. For the gve_rx_poll and
    gve_xdp_poll, they were mistakenly taking the 0 budget as the indication
    to do all the work. Add check to avoid the rx path and xdp path being
    called when budget is 0. And also avoid napi_complete_done being called
    when budget is 0 for netpoll.
    
    Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
    Signed-off-by: Ziwei Xiao <ziweixiao@google.com>
    Link: https://lore.kernel.org/r/20231114004144.2022268-1-ziweixiao@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
    Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec0b877d1520377a57387bf9c4aa03136fe87fb
Author: Zhang Zekun <zhangzekun11@huawei.com>
Date:   Wed Dec 4 16:27:52 2024 +0800

    Revert "drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()"
    
    This reverts commit 25d7e84343e1235b667cf5226c3934fdf36f0df6.
    
    The origin mainline patch fix a buffer overflow issue in
    amdgpu_debugfs_gprwave_read(), but it has not been introduced in kernel
    6.1 and older kernels. This patch add a check in a wrong function in the
    same file.
    
    Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ed23e9dd86a9621cb86d7a7945def2e8d49365e
Author: Heming Zhao <heming.zhao@suse.com>
Date:   Thu Dec 12 19:31:05 2024 +0800

    ocfs2: Revert "ocfs2: fix the la space leak when unmounting an ocfs2 volume"
    
    This reverts commit dfe6c5692fb5 ("ocfs2: fix the la space leak when
    unmounting an ocfs2 volume").
    
    In commit dfe6c5692fb5, the commit log "This bug has existed since the
    initial OCFS2 code." is wrong. The correct introduction commit is
    30dd3478c3cd ("ocfs2: correctly use ocfs2_find_next_zero_bit()").
    
    The influence of commit dfe6c5692fb5 is that it provides a correct
    fix for the latest kernel. however, it shouldn't be pushed to stable
    branches. Let's use this commit to revert all branches that include
    dfe6c5692fb5 and use a new fix method to fix commit 30dd3478c3cd.
    
    Fixes: dfe6c5692fb5 ("ocfs2: fix the la space leak when unmounting an ocfs2 volume")
    Signed-off-by: Heming Zhao <heming.zhao@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eef7301e674438913134539e77dd887960949f20
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Jun 3 08:24:13 2024 -0600

    drm/amd/display: Check BIOS images before it is used
    
    commit 8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c upstream.
    
    BIOS images may fail to load and null checks are added before they are
    used.
    
    This fixes 6 NULL_RETURNS issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Keerthana K <keerthana.kalyanasundaram@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40aed32594445c904cab83232068832f8cae8ba6
Author: Andy-ld Lu <andy-ld.lu@mediatek.com>
Date:   Thu Nov 7 20:11:21 2024 +0800

    mmc: mtk-sd: Fix error handle of probe function
    
    commit 291220451c775a054cedc4fab4578a1419eb6256 upstream.
    
    In the probe function, it goes to 'release_mem' label and returns after
    some procedure failure. But if the clocks (partial or all) have been
    enabled previously, they would not be disabled in msdc_runtime_suspend,
    since runtime PM is not yet enabled for this case.
    
    That cause mmc related clocks always on during system suspend and block
    suspend flow. Below log is from a SDCard issue of MT8196 chromebook, it
    returns -ETIMEOUT while polling clock stable in the msdc_ungate_clock()
    and probe failed, but the enabled clocks could not be disabled anyway.
    
    [  129.059253] clk_chk_dev_pm_suspend()
    [  129.350119] suspend warning: msdcpll is on
    [  129.354494] [ck_msdc30_1_sel : enabled, 1, 1, 191999939,   ck_msdcpll_d2]
    [  129.362787] [ck_msdcpll_d2   : enabled, 1, 1, 191999939,         msdcpll]
    [  129.371041] [ck_msdc30_1_ck  : enabled, 1, 1, 191999939, ck_msdc30_1_sel]
    [  129.379295] [msdcpll         : enabled, 1, 1, 383999878,          clk26m]
    
    Add a new 'release_clk' label and reorder the error handle functions to
    make sure the clocks be disabled after probe failure.
    
    Fixes: ffaea6ebfe9c ("mmc: mtk-sd: Use readl_poll_timeout instead of open-coded polling")
    Fixes: 7a2fa8eed936 ("mmc: mtk-sd: use devm_mmc_alloc_host")
    Signed-off-by: Andy-ld Lu <andy-ld.lu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: stable@vger.kernel.org
    Message-ID: <20241107121215.5201-1-andy-ld.lu@mediatek.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca5c9cb64721758b6a9c93e4509a162828f9bffd
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Sep 5 17:32:49 2024 +0300

    xhci: dbc: Fix STALL transfer event handling
    
    commit 9044ad57b60b0556d42b6f8aa218a68865e810a4 upstream.
    
    Don't flush all pending DbC data requests when an endpoint halts.
    
    An endpoint may halt and xHC DbC triggers a STALL error event if there's
    an issue with a bulk data transfer. The transfer should restart once xHC
    DbC receives a ClearFeature(ENDPOINT_HALT) request from the host.
    
    Once xHC DbC restarts it will start from the TRB pointed to by dequeue
    field in the endpoint context, which might be the same TRB we got the
    STALL event for. Turn the TRB to a no-op in this case to make sure xHC
    DbC doesn't reuse and tries to retransmit this same TRB after we already
    handled it, and gave its corresponding data request back.
    
    Other STALL events might be completely bogus.
    Lukasz Bartosik discovered that xHC DbC might issue spurious STALL events
    if hosts sends a ClearFeature(ENDPOINT_HALT) request to non-halted
    endpoints even without any active bulk transfers.
    
    Assume STALL event is spurious if it reports 0 bytes transferred, and
    the endpoint stopped on the STALLED TRB.
    Don't give back the data request corresponding to the TRB in this case.
    
    The halted status is per endpoint. Track it with a per endpoint flag
    instead of the driver invented DbC wide DS_STALLED state.
    DbC remains in DbC-Configured state even if endpoints halt. There is no
    Stalled state in the DbC Port state Machine (xhci section 7.6.6)
    
    Reported-by: Łukasz Bartosik <ukaszb@chromium.org>
    Closes: https://lore.kernel.org/linux-usb/20240725074857.623299-1-ukaszb@chromium.org/
    Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240905143300.1959279-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ab9326f93ec4471cab6f2107ecdf0cf6a8615aa
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Jan 9 14:46:10 2023 +0000

    io_uring: wake up optimisations
    
    commit 3181e22fb79910c7071e84a43af93ac89e8a7106 upstream.
    
    Flush completions is done either from the submit syscall or by the
    task_work, both are in the context of the submitter task, and when it
    goes for a single threaded rings like implied by ->task_complete, there
    won't be any waiters on ->cq_wait but the master task. That means that
    there can be no tasks sleeping on cq_wait while we run
    __io_submit_flush_completions() and so waking up can be skipped.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/60ad9768ec74435a0ddaa6eec0ffa7729474f69f.1673274244.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d5c04d26d35e7b1b2aa5db8bf2f3ca96d71cd51
Author: Zheng Yejian <zhengyejian@huaweicloud.com>
Date:   Tue Oct 22 16:39:26 2024 +0800

    mm/damon/vaddr: fix issue in damon_va_evenly_split_region()
    
    commit f3c7a1ede435e2e45177d7a490a85fb0a0ec96d1 upstream.
    
    Patch series "mm/damon/vaddr: Fix issue in
    damon_va_evenly_split_region()".  v2.
    
    According to the logic of damon_va_evenly_split_region(), currently
    following split case would not meet the expectation:
    
      Suppose DAMON_MIN_REGION=0x1000,
      Case: Split [0x0, 0x3000) into 2 pieces, then the result would be
            acutually 3 regions:
              [0x0, 0x1000), [0x1000, 0x2000), [0x2000, 0x3000)
            but NOT the expected 2 regions:
              [0x0, 0x1000), [0x1000, 0x3000) !!!
    
    The root cause is that when calculating size of each split piece in
    damon_va_evenly_split_region():
    
      `sz_piece = ALIGN_DOWN(sz_orig / nr_pieces, DAMON_MIN_REGION);`
    
    both the dividing and the ALIGN_DOWN may cause loss of precision, then
    each time split one piece of size 'sz_piece' from origin 'start' to 'end'
    would cause more pieces are split out than expected!!!
    
    To fix it, count for each piece split and make sure no more than
    'nr_pieces'.  In addition, add above case into damon_test_split_evenly().
    
    And add 'nr_piece == 1' check in damon_va_evenly_split_region() for better
    code readability and add a corresponding kunit testcase.
    
    
    This patch (of 2):
    
    According to the logic of damon_va_evenly_split_region(), currently
    following split case would not meet the expectation:
    
      Suppose DAMON_MIN_REGION=0x1000,
      Case: Split [0x0, 0x3000) into 2 pieces, then the result would be
            acutually 3 regions:
              [0x0, 0x1000), [0x1000, 0x2000), [0x2000, 0x3000)
            but NOT the expected 2 regions:
              [0x0, 0x1000), [0x1000, 0x3000) !!!
    
    The root cause is that when calculating size of each split piece in
    damon_va_evenly_split_region():
    
      `sz_piece = ALIGN_DOWN(sz_orig / nr_pieces, DAMON_MIN_REGION);`
    
    both the dividing and the ALIGN_DOWN may cause loss of precision,
    then each time split one piece of size 'sz_piece' from origin 'start' to
    'end' would cause more pieces are split out than expected!!!
    
    To fix it, count for each piece split and make sure no more than
    'nr_pieces'. In addition, add above case into damon_test_split_evenly().
    
    After this patch, damon-operations test passed:
    
     # ./tools/testing/kunit/kunit.py run damon-operations
     [...]
     ============== damon-operations (6 subtests) ===============
     [PASSED] damon_test_three_regions_in_vmas
     [PASSED] damon_test_apply_three_regions1
     [PASSED] damon_test_apply_three_regions2
     [PASSED] damon_test_apply_three_regions3
     [PASSED] damon_test_apply_three_regions4
     [PASSED] damon_test_split_evenly
     ================ [PASSED] damon-operations =================
    
    Link: https://lkml.kernel.org/r/20241022083927.3592237-1-zhengyejian@huaweicloud.com
    Link: https://lkml.kernel.org/r/20241022083927.3592237-2-zhengyejian@huaweicloud.com
    Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces")
    Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
    Reviewed-by: SeongJae Park <sj@kernel.org>
    Cc: Fernand Sieber <sieberf@amazon.com>
    Cc: Leonard Foerster <foersleo@amazon.de>
    Cc: Shakeel Butt <shakeel.butt@linux.dev>
    Cc: Ye Weihua <yeweihua4@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd16397b47e3f6a1ce63e90e2f939eb1f2adc1c1
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Dec 3 12:27:15 2024 +0100

    jffs2: Fix rtime decompressor
    
    commit b29bf7119d6bbfd04aabb8d82b060fe2a33ef890 upstream.
    
    The fix for a memory corruption contained a off-by-one error and
    caused the compressor to fail in legit cases.
    
    Cc: Kinsey Moore <kinsey.moore@oarcorp.com>
    Cc: stable@vger.kernel.org
    Fixes: fe051552f5078 ("jffs2: Prevent rtime decompress memory corruption")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47c9a7f81027a78afea9d2e9a54bfd8fabb6b3d0
Author: Kinsey Moore <kinsey.moore@oarcorp.com>
Date:   Tue Jul 23 15:58:05 2024 -0500

    jffs2: Prevent rtime decompress memory corruption
    
    commit fe051552f5078fa02d593847529a3884305a6ffe upstream.
    
    The rtime decompression routine does not fully check bounds during the
    entirety of the decompression pass and can corrupt memory outside the
    decompression buffer if the compressed data is corrupted. This adds the
    required check to prevent this failure mode.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Kinsey Moore <kinsey.moore@oarcorp.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4118bd1834a9cf6b4c328fe25064129ee4d17701
Author: Nikolay Kuratov <kniv@yandex-team.ru>
Date:   Sun Dec 8 11:37:43 2024 +0300

    KVM: x86/mmu: Ensure that kvm_release_pfn_clean() takes exact pfn from kvm_faultin_pfn()
    
    Since 5.16 and prior to 6.13 KVM can't be used with FSDAX
    guest memory (PMD pages). To reproduce the issue you need to reserve
    guest memory with `memmap=` cmdline, create and mount FS in DAX mode
    (tested both XFS and ext4), see doc link below. ndctl command for test:
    ndctl create-namespace -v -e namespace1.0 --map=dev --mode=fsdax -a 2M
    Then pass memory object to qemu like:
    -m 8G -object memory-backend-file,id=ram0,size=8G,\
    mem-path=/mnt/pmem/guestmem,share=on,prealloc=on,dump=off,align=2097152 \
    -numa node,memdev=ram0,cpus=0-1
    QEMU fails to run guest with error: kvm run failed Bad address
    and there are two warnings in dmesg:
    WARN_ON_ONCE(!page_count(page)) in kvm_is_zone_device_page() and
    WARN_ON_ONCE(folio_ref_count(folio) <= 0) in try_grab_folio() (v6.6.63)
    
    It looks like in the past assumption was made that pfn won't change from
    faultin_pfn() to release_pfn_clean(), e.g. see
    commit 4cd071d13c5c ("KVM: x86/mmu: Move calls to thp_adjust() down a level")
    But kvm_page_fault structure made pfn part of mutable state, so
    now release_pfn_clean() can take hugepage-adjusted pfn.
    And it works for all cases (/dev/shm, hugetlb, devdax) except fsdax.
    Apparently in fsdax mode faultin-pfn and adjusted-pfn may refer to
    different folios, so we're getting get_page/put_page imbalance.
    
    To solve this preserve faultin pfn in separate local variable
    and pass it in kvm_release_pfn_clean().
    
    Patch tested for all mentioned guest memory backends with tdp_mmu={0,1}.
    
    No bug in upstream as it was solved fundamentally by
    commit 8dd861cc07e2 ("KVM: x86/mmu: Put refcounted pages instead of blindly releasing pfns")
    and related patch series.
    
    Link: https://nvdimm.docs.kernel.org/2mib_fs_dax.html
    Fixes: 2f6305dd5676 ("KVM: MMU: change kvm_tdp_mmu_map() arguments to kvm_page_fault")
    Co-developed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21bc72eef08a42e793aee3c5267fd1961a21bc54
Author: Kunkun Jiang <jiangkunkun@huawei.com>
Date:   Wed Dec 4 12:23:57 2024 -0800

    KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE
    
    commit 7602ffd1d5e8927fadd5187cb4aed2fdc9c47143 upstream.
    
    When DISCARD frees an ITE, it does not invalidate the
    corresponding ITE. In the scenario of continuous saves and
    restores, there may be a situation where an ITE is not saved
    but is restored. This is unreasonable and may cause restore
    to fail. This patch clears the corresponding ITE when DISCARD
    frees an ITE.
    
    Cc: stable@vger.kernel.org
    Fixes: eff484e0298d ("KVM: arm64: vgic-its: ITT save and restore")
    Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
    [Jing: Update with entry write helper]
    Signed-off-by: Jing Zhang <jingzhangos@google.com>
    Link: https://lore.kernel.org/r/20241107214137.428439-6-jingzhangos@google.com
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe695bc1572c030b17a68d8ec7d3d60a486131fd
Author: Kunkun Jiang <jiangkunkun@huawei.com>
Date:   Wed Dec 4 12:23:56 2024 -0800

    KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device
    
    commit e9649129d33dca561305fc590a7c4ba8c3e5675a upstream.
    
    vgic_its_save_device_tables will traverse its->device_list to
    save DTE for each device. vgic_its_restore_device_tables will
    traverse each entry of device table and check if it is valid.
    Restore if valid.
    
    But when MAPD unmaps a device, it does not invalidate the
    corresponding DTE. In the scenario of continuous saves
    and restores, there may be a situation where a device's DTE
    is not saved but is restored. This is unreasonable and may
    cause restore to fail. This patch clears the corresponding
    DTE when MAPD unmaps a device.
    
    Cc: stable@vger.kernel.org
    Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore")
    Co-developed-by: Shusen Li <lishusen2@huawei.com>
    Signed-off-by: Shusen Li <lishusen2@huawei.com>
    Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
    [Jing: Update with entry write helper]
    Signed-off-by: Jing Zhang <jingzhangos@google.com>
    Link: https://lore.kernel.org/r/20241107214137.428439-5-jingzhangos@google.com
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb354450527a905607a86d44dc42498136fd037b
Author: Jing Zhang <jingzhangos@google.com>
Date:   Wed Dec 4 12:23:55 2024 -0800

    KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*
    
    commit 7fe28d7e68f92cc3d0668b8f2fbdf5c303ac3022 upstream.
    
    In all the vgic_its_save_*() functinos, they do not check whether
    the data length is 8 bytes before calling vgic_write_guest_lock.
    This patch adds the check. To prevent the kernel from being blown up
    when the fault occurs, KVM_BUG_ON() is used. And the other BUG_ON()s
    are replaced together.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
    [Jing: Update with the new entry read/write helpers]
    Signed-off-by: Jing Zhang <jingzhangos@google.com>
    Link: https://lore.kernel.org/r/20241107214137.428439-4-jingzhangos@google.com
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eed8395d9486dec50ea7fab2800fbf2e084c8d05
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 18 15:33:41 2023 +0100

    udf: Fold udf_getblk() into udf_bread()
    
    commit 32f123a3f34283f9c6446de87861696f0502b02e upstream.
    
    udf_getblk() has a single call site. Fold it there.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    [acsjakub: backport-adjusting changes
     udf_getblk() has changed between 6.1 and the backported commit, namely
     in commit 541e047b14c8 ("udf: Use udf_map_block() in udf_getblk()")
     Backport using the form of udf_getblk present in 6.1., that means use
     udf_get_block() instead of udf_map_block() and use dummy in buffer_new()
     and buffer_mapped(). ]
    Closes: https://syzkaller.appspot.com/bug?extid=a38e34ca637c224f4a79
    Signed-off-by: Jakub Acs <acsjakub@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97c22fd510c5d42eca74b8ef071ac78914bcac5b
Author: Yishai Hadas <yishaih@nvidia.com>
Date:   Thu Dec 5 14:26:54 2024 +0200

    vfio/mlx5: Align the page tracking max message size with the device capability
    
    [ Upstream commit 9c7c5430bca36e9636eabbba0b3b53251479c7ab ]
    
    Align the page tracking maximum message size with the device's
    capability instead of relying on PAGE_SIZE.
    
    This adjustment resolves a mismatch on systems where PAGE_SIZE is 64K,
    but the firmware only supports a maximum message size of 4K.
    
    Now that we rely on the device's capability for max_message_size, we
    must account for potential future increases in its value.
    
    Key considerations include:
    - Supporting message sizes that exceed a single system page (e.g., an 8K
      message on a 4K system).
    - Ensuring the RQ size is adjusted to accommodate at least 4
      WQEs/messages, in line with the device specification.
    
    The above has been addressed as part of the patch.
    
    Fixes: 79c3cf279926 ("vfio/mlx5: Init QP based resources for dirty tracking")
    Reviewed-by: Cédric Le Goater <clg@redhat.com>
    Tested-by: Yingshun Cui <yicui@redhat.com>
    Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
    Link: https://lore.kernel.org/r/20241205122654.235619-1-yishaih@nvidia.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca8e6a73690c143e8b17376b08778952b986fc93
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Dec 11 14:11:23 2024 -0800

    Revert "unicode: Don't special case ignorable code points"
    
    [ Upstream commit 231825b2e1ff6ba799c5eaf396d3ab2354e37c6b ]
    
    This reverts commit 5c26d2f1d3f5e4be3e196526bead29ecb139cf91.
    
    It turns out that we can't do this, because while the old behavior of
    ignoring ignorable code points was most definitely wrong, we have
    case-folding filesystems with on-disk hash values with that wrong
    behavior.
    
    So now you can't look up those names, because they hash to something
    different.
    
    Of course, it's also entirely possible that in the meantime people have
    created *new* files with the new ("more correct") case folding logic,
    and reverting will just make other things break.
    
    The correct solution is to not do case folding in filesystems, but
    sadly, people seem to never really understand that.  People still see it
    as a feature, not a bug.
    
    Reported-by: Qi Han <hanqi@vivo.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219586
    Cc: Gabriel Krisman Bertazi <krisman@suse.de>
    Requested-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db774504be998a5f1070539f311a4144ffaa862f
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Sat Nov 30 01:47:47 2024 +0900

    tracing/eprobe: Fix to release eprobe when failed to add dyn_event
    
    [ Upstream commit 494b332064c0ce2f7392fa92632bc50191c1b517 ]
    
    Fix eprobe event to unregister event call and release eprobe when it fails
    to add dynamic event correctly.
    
    Link: https://lore.kernel.org/all/173289886698.73724.1959899350183686006.stgit@devnote2/
    
    Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b15437fb260f93c31c172e5a8e8a4ab13b934e5a
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Nov 29 13:33:03 2024 +0000

    btrfs: fix missing snapshot drew unlock when root is dead during swap activation
    
    [ Upstream commit 9c803c474c6c002d8ade68ebe99026cc39c37f85 ]
    
    When activating a swap file we acquire the root's snapshot drew lock and
    then check if the root is dead, failing and returning with -EPERM if it's
    dead but without unlocking the root's snapshot lock. Fix this by adding
    the missing unlock.
    
    Fixes: 60021bd754c6 ("btrfs: prevent subvol with swapfile from being deleted")
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 641e9638aadfa88f1b3e5aff51e3fe144655b841
Author: K Prateek Nayak <kprateek.nayak@amd.com>
Date:   Tue Nov 19 05:44:32 2024 +0000

    sched/core: Prevent wakeup of ksoftirqd during idle load balance
    
    [ Upstream commit e932c4ab38f072ce5894b2851fea8bc5754bb8e5 ]
    
    Scheduler raises a SCHED_SOFTIRQ to trigger a load balancing event on
    from the IPI handler on the idle CPU. If the SMP function is invoked
    from an idle CPU via flush_smp_call_function_queue() then the HARD-IRQ
    flag is not set and raise_softirq_irqoff() needlessly wakes ksoftirqd
    because soft interrupts are handled before ksoftirqd get on the CPU.
    
    Adding a trace_printk() in nohz_csd_func() at the spot of raising
    SCHED_SOFTIRQ and enabling trace events for sched_switch, sched_wakeup,
    and softirq_entry (for SCHED_SOFTIRQ vector alone) helps observing the
    current behavior:
    
           <idle>-0   [000] dN.1.:  nohz_csd_func: Raising SCHED_SOFTIRQ from nohz_csd_func
           <idle>-0   [000] dN.4.:  sched_wakeup: comm=ksoftirqd/0 pid=16 prio=120 target_cpu=000
           <idle>-0   [000] .Ns1.:  softirq_entry: vec=7 [action=SCHED]
           <idle>-0   [000] .Ns1.:  softirq_exit: vec=7  [action=SCHED]
           <idle>-0   [000] d..2.:  sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=ksoftirqd/0 next_pid=16 next_prio=120
      ksoftirqd/0-16  [000] d..2.:  sched_switch: prev_comm=ksoftirqd/0 prev_pid=16 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
           ...
    
    Use __raise_softirq_irqoff() to raise the softirq. The SMP function call
    is always invoked on the requested CPU in an interrupt handler. It is
    guaranteed that soft interrupts are handled at the end.
    
    Following are the observations with the changes when enabling the same
    set of events:
    
           <idle>-0       [000] dN.1.: nohz_csd_func: Raising SCHED_SOFTIRQ for nohz_idle_balance
           <idle>-0       [000] dN.1.: softirq_raise: vec=7 [action=SCHED]
           <idle>-0       [000] .Ns1.: softirq_entry: vec=7 [action=SCHED]
    
    No unnecessary ksoftirqd wakeups are seen from idle task's context to
    service the softirq.
    
    Fixes: b2a02fc43a1f ("smp: Optimize send_call_function_single_ipi()")
    Closes: https://lore.kernel.org/lkml/fcf823f-195e-6c9a-eac3-25f870cb35ac@inria.fr/ [1]
    Reported-by: Julia Lawall <julia.lawall@inria.fr>
    Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20241119054432.6405-5-kprateek.nayak@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4a4250cf53dcfdc5c9cf3bfea26abb0682a5197
Author: K Prateek Nayak <kprateek.nayak@amd.com>
Date:   Tue Nov 19 05:44:31 2024 +0000

    sched/fair: Check idle_cpu() before need_resched() to detect ilb CPU turning busy
    
    [ Upstream commit ff47a0acfcce309cf9e175149c75614491953c8f ]
    
    Commit b2a02fc43a1f ("smp: Optimize send_call_function_single_ipi()")
    optimizes IPIs to idle CPUs in TIF_POLLING_NRFLAG mode by setting the
    TIF_NEED_RESCHED flag in idle task's thread info and relying on
    flush_smp_call_function_queue() in idle exit path to run the
    call-function. A softirq raised by the call-function is handled shortly
    after in do_softirq_post_smp_call_flush() but the TIF_NEED_RESCHED flag
    remains set and is only cleared later when schedule_idle() calls
    __schedule().
    
    need_resched() check in _nohz_idle_balance() exists to bail out of load
    balancing if another task has woken up on the CPU currently in-charge of
    idle load balancing which is being processed in SCHED_SOFTIRQ context.
    Since the optimization mentioned above overloads the interpretation of
    TIF_NEED_RESCHED, check for idle_cpu() before going with the existing
    need_resched() check which can catch a genuine task wakeup on an idle
    CPU processing SCHED_SOFTIRQ from do_softirq_post_smp_call_flush(), as
    well as the case where ksoftirqd needs to be preempted as a result of
    new task wakeup or slice expiry.
    
    In case of PREEMPT_RT or threadirqs, although the idle load balancing
    may be inhibited in some cases on the ilb CPU, the fact that ksoftirqd
    is the only fair task going back to sleep will trigger a newidle balance
    on the CPU which will alleviate some imbalance if it exists if idle
    balance fails to do so.
    
    Fixes: b2a02fc43a1f ("smp: Optimize send_call_function_single_ipi()")
    Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241119054432.6405-4-kprateek.nayak@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77912496064a73da31948b58985b1c54255197d6
Author: K Prateek Nayak <kprateek.nayak@amd.com>
Date:   Tue Nov 19 05:44:30 2024 +0000

    sched/core: Remove the unnecessary need_resched() check in nohz_csd_func()
    
    [ Upstream commit ea9cffc0a154124821531991d5afdd7e8b20d7aa ]
    
    The need_resched() check currently in nohz_csd_func() can be tracked
    to have been added in scheduler_ipi() back in 2011 via commit
    ca38062e57e9 ("sched: Use resched IPI to kick off the nohz idle balance")
    
    Since then, it has travelled quite a bit but it seems like an idle_cpu()
    check currently is sufficient to detect the need to bail out from an
    idle load balancing. To justify this removal, consider all the following
    case where an idle load balancing could race with a task wakeup:
    
    o Since commit f3dd3f674555b ("sched: Remove the limitation of WF_ON_CPU
      on wakelist if wakee cpu is idle") a target perceived to be idle
      (target_rq->nr_running == 0) will return true for
      ttwu_queue_cond(target) which will offload the task wakeup to the idle
      target via an IPI.
    
      In all such cases target_rq->ttwu_pending will be set to 1 before
      queuing the wake function.
    
      If an idle load balance races here, following scenarios are possible:
    
      - The CPU is not in TIF_POLLING_NRFLAG mode in which case an actual
        IPI is sent to the CPU to wake it out of idle. If the
        nohz_csd_func() queues before sched_ttwu_pending(), the idle load
        balance will bail out since idle_cpu(target) returns 0 since
        target_rq->ttwu_pending is 1. If the nohz_csd_func() is queued after
        sched_ttwu_pending() it should see rq->nr_running to be non-zero and
        bail out of idle load balancing.
    
      - The CPU is in TIF_POLLING_NRFLAG mode and instead of an actual IPI,
        the sender will simply set TIF_NEED_RESCHED for the target to put it
        out of idle and flush_smp_call_function_queue() in do_idle() will
        execute the call function. Depending on the ordering of the queuing
        of nohz_csd_func() and sched_ttwu_pending(), the idle_cpu() check in
        nohz_csd_func() should either see target_rq->ttwu_pending = 1 or
        target_rq->nr_running to be non-zero if there is a genuine task
        wakeup racing with the idle load balance kick.
    
    o The waker CPU perceives the target CPU to be busy
      (targer_rq->nr_running != 0) but the CPU is in fact going idle and due
      to a series of unfortunate events, the system reaches a case where the
      waker CPU decides to perform the wakeup by itself in ttwu_queue() on
      the target CPU but target is concurrently selected for idle load
      balance (XXX: Can this happen? I'm not sure, but we'll consider the
      mother of all coincidences to estimate the worst case scenario).
    
      ttwu_do_activate() calls enqueue_task() which would increment
      "rq->nr_running" post which it calls wakeup_preempt() which is
      responsible for setting TIF_NEED_RESCHED (via a resched IPI or by
      setting TIF_NEED_RESCHED on a TIF_POLLING_NRFLAG idle CPU) The key
      thing to note in this case is that rq->nr_running is already non-zero
      in case of a wakeup before TIF_NEED_RESCHED is set which would
      lead to idle_cpu() check returning false.
    
    In all cases, it seems that need_resched() check is unnecessary when
    checking for idle_cpu() first since an impending wakeup racing with idle
    load balancer will either set the "rq->ttwu_pending" or indicate a newly
    woken task via "rq->nr_running".
    
    Chasing the reason why this check might have existed in the first place,
    I came across  Peter's suggestion on the fist iteration of Suresh's
    patch from 2011 [1] where the condition to raise the SCHED_SOFTIRQ was:
    
            sched_ttwu_do_pending(list);
    
            if (unlikely((rq->idle == current) &&
                rq->nohz_balance_kick &&
                !need_resched()))
                    raise_softirq_irqoff(SCHED_SOFTIRQ);
    
    Since the condition to raise the SCHED_SOFIRQ was preceded by
    sched_ttwu_do_pending() (which is equivalent of sched_ttwu_pending()) in
    the current upstream kernel, the need_resched() check was necessary to
    catch a newly queued task. Peter suggested modifying it to:
    
            if (idle_cpu() && rq->nohz_balance_kick && !need_resched())
                    raise_softirq_irqoff(SCHED_SOFTIRQ);
    
    where idle_cpu() seems to have replaced "rq->idle == current" check.
    
    Even back then, the idle_cpu() check would have been sufficient to catch
    a new task being enqueued. Since commit b2a02fc43a1f ("smp: Optimize
    send_call_function_single_ipi()") overloads the interpretation of
    TIF_NEED_RESCHED for TIF_POLLING_NRFLAG idling, remove the
    need_resched() check in nohz_csd_func() to raise SCHED_SOFTIRQ based
    on Peter's suggestion.
    
    Fixes: b2a02fc43a1f ("smp: Optimize send_call_function_single_ipi()")
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241119054432.6405-3-kprateek.nayak@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74b6d260cb7a62c370e31f4ad1ae3177510d0497
Author: Jared Kangas <jkangas@redhat.com>
Date:   Tue Nov 19 13:02:34 2024 -0800

    kasan: make report_lock a raw spinlock
    
    [ Upstream commit e30a0361b8515d424c73c67de1a43e45a13b8ba2 ]
    
    If PREEMPT_RT is enabled, report_lock is a sleeping spinlock and must not
    be locked when IRQs are disabled.  However, KASAN reports may be triggered
    in such contexts.  For example:
    
            char *s = kzalloc(1, GFP_KERNEL);
            kfree(s);
            local_irq_disable();
            char c = *s;  /* KASAN report here leads to spin_lock() */
            local_irq_enable();
    
    Make report_spinlock a raw spinlock to prevent rescheduling when
    PREEMPT_RT is enabled.
    
    Link: https://lkml.kernel.org/r/20241119210234.1602529-1-jkangas@redhat.com
    Fixes: 342a93247e08 ("locking/spinlock: Provide RT variant header: <linux/spinlock_rt.h>")
    Signed-off-by: Jared Kangas <jkangas@redhat.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac77fe0577ca694d7689bb60da939dc8d25fa2dd
Author: Andrey Konovalov <andreyknvl@gmail.com>
Date:   Sat Mar 11 00:43:33 2023 +0100

    kasan: suppress recursive reports for HW_TAGS
    
    [ Upstream commit c6a690e0c978bda8106e7a489c13323f90b087d0 ]
    
    KASAN suppresses reports for bad accesses done by the KASAN reporting
    code.  The reporting code might access poisoned memory for reporting
    purposes.
    
    Software KASAN modes do this by suppressing reports during reporting via
    current->kasan_depth, the same way they suppress reports during accesses
    to poisoned slab metadata.
    
    Hardware Tag-Based KASAN does not use current->kasan_depth, and instead
    resets pointer tags for accesses to poisoned memory done by the reporting
    code.
    
    Despite that, a recursive report can still happen:
    
    1. On hardware with faulty MTE support. This was observed by Weizhao
       Ouyang on a faulty hardware that caused memory tags to randomly change
       from time to time.
    
    2. Theoretically, due to a previous MTE-undetected memory corruption.
    
    A recursive report can happen via:
    
    1. Accessing a pointer with a non-reset tag in the reporting code, e.g.
       slab->slab_cache, which is what Weizhao Ouyang observed.
    
    2. Theoretically, via external non-annotated routines, e.g. stackdepot.
    
    To resolve this issue, resetting tags for all of the pointers in the
    reporting code and all the used external routines would be impractical.
    
    Instead, disable tag checking done by the CPU for the duration of KASAN
    reporting for Hardware Tag-Based KASAN.
    
    Without this fix, Hardware Tag-Based KASAN reporting code might deadlock.
    
    [andreyknvl@google.com: disable preemption instead of migration, fix comment typo]
      Link: https://lkml.kernel.org/r/d14417c8bc5eea7589e99381203432f15c0f9138.1680114854.git.andreyknvl@google.com
    Link: https://lkml.kernel.org/r/59f433e00f7fa985e8bf9f7caf78574db16b67ab.1678491668.git.andreyknvl@google.com
    Fixes: 2e903b914797 ("kasan, arm64: implement HW_TAGS runtime")
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Reported-by: Weizhao Ouyang <ouyangweizhao@zeku.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Evgenii Stepanov <eugenis@google.com>
    Cc: Peter Collingbourne <pcc@google.com>
    Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: e30a0361b851 ("kasan: make report_lock a raw spinlock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94ad56f61b873ffeebcc620d451eacfbdf9d40f0
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Nov 29 07:20:28 2024 -0700

    io_uring/tctx: work around xa_store() allocation error issue
    
    [ Upstream commit 7eb75ce7527129d7f1fee6951566af409a37a1c4 ]
    
    syzbot triggered the following WARN_ON:
    
    WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51
    
    which is the
    
    WARN_ON_ONCE(!xa_empty(&tctx->xa));
    
    sanity check in __io_uring_free() when a io_uring_task is going through
    its final put. The syzbot test case includes injecting memory allocation
    failures, and it very much looks like xa_store() can fail one of its
    memory allocations and end up with ->head being non-NULL even though no
    entries exist in the xarray.
    
    Until this issue gets sorted out, work around it by attempting to
    iterate entries in our xarray, and WARN_ON_ONCE() if one is found.
    
    Reported-by: syzbot+cc36d44ec9f368e443d3@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/io-uring/673c1643.050a0220.87769.0066.GAE@google.com/
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3613d540c1f3b2b629bcc38119966137353db4c2
Author: Inochi Amaoto <inochiama@gmail.com>
Date:   Thu Oct 24 14:21:03 2024 +0800

    serial: 8250_dw: Add Sophgo SG2044 quirk
    
    [ Upstream commit cad4dda82c7eedcfc22597267e710ccbcf39d572 ]
    
    SG2044 relys on an internal divisor when calculating bitrate, which
    means a wrong clock for the most common bitrates. So add a quirk for
    this uart device to skip the set rate call and only relys on the
    internal UART divisor.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
    Link: https://lore.kernel.org/r/20241024062105.782330-4-inochiama@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c9502ac832ab650528d50e14f8b752bf5175e5c
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Oct 25 13:14:57 2024 -0700

    rtc: cmos: avoid taking rtc_lock for extended period of time
    
    [ Upstream commit 0a6efab33eab4e973db26d9f90c3e97a7a82e399 ]
    
    On my device reading entirety of /sys/devices/pnp0/00:03/cmos_nvram0/nvmem
    takes about 9 msec during which time interrupts are off on the CPU that
    does the read and the thread that performs the read can not be migrated
    or preempted by another higher priority thread (RT or not).
    
    Allow readers and writers be preempted by taking and releasing rtc_lock
    spinlock for each individual byte read or written rather than once per
    read/write request.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Link: https://lore.kernel.org/r/Zxv8QWR21AV4ztC5@google.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80be263f3f453b6e8efc2e5809347dc9ae7c3e29
Author: Parker Newman <pnewman@connecttech.com>
Date:   Wed Oct 2 11:12:33 2024 -0400

    misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle
    
    [ Upstream commit 7738a7ab9d12c5371ed97114ee2132d4512e9fd5 ]
    
    Add a quirk similar to eeprom_93xx46 to add an extra clock cycle before
    reading data from the EEPROM.
    
    The 93Cx6 family of EEPROMs output a "dummy 0 bit" between the writing
    of the op-code/address from the host to the EEPROM and the reading of
    the actual data from the EEPROM.
    
    More info can be found on page 6 of the AT93C46 datasheet (linked below).
    Similar notes are found in other 93xx6 datasheets.
    
    In summary the read operation for a 93Cx6 EEPROM is:
    Write to EEPROM:        110[A5-A0]      (9 bits)
    Read from EEPROM:       0[D15-D0]       (17 bits)
    
    Where:
            110 is the start bit and READ OpCode
            [A5-A0] is the address to read from
            0 is a "dummy bit" preceding the actual data
            [D15-D0] is the actual data.
    
    Looking at the READ timing diagrams in the 93Cx6 datasheets the dummy
    bit should be clocked out on the last address bit clock cycle meaning it
    should be discarded naturally.
    
    However, depending on the hardware configuration sometimes this dummy
    bit is not discarded. This is the case with Exar PCI UARTs which require
    an extra clock cycle between sending the address and reading the data.
    
    Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-5193-SEEPROM-AT93C46D-Datasheet.pdf
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Parker Newman <pnewman@connecttech.com>
    Link: https://lore.kernel.org/r/0f23973efefccd2544705a0480b4ad4c2353e407.1727880931.git.pnewman@connecttech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d5f0453a2228607333bff0c85238a3cb495d194
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Nov 26 13:57:10 2024 +1100

    powerpc/prom_init: Fixup missing powermac #size-cells
    
    [ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
    
    On some powermacs `escc` nodes are missing `#size-cells` properties,
    which is deprecated and now triggers a warning at boot since commit
    045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
    handling").
    
    For example:
    
      Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000
      WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108
      Hardware name: PowerMac3,1 7400 0xc0209 PowerMac
      ...
      Call Trace:
        of_bus_n_size_cells+0x98/0x108 (unreliable)
        of_bus_default_count_cells+0x40/0x60
        __of_get_address+0xc8/0x21c
        __of_address_to_resource+0x5c/0x228
        pmz_init_port+0x5c/0x2ec
        pmz_probe.isra.0+0x144/0x1e4
        pmz_console_init+0x10/0x48
        console_init+0xcc/0x138
        start_kernel+0x5c4/0x694
    
    As powermacs boot via prom_init it's possible to add the missing
    properties to the device tree during boot, avoiding the warning. Note
    that `escc-legacy` nodes are also missing `#size-cells` properties, but
    they are skipped by the macio driver, so leave them alone.
    
    Depends-on: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20241126025710.591683-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c239c3c004e5eefb8cae5a4e61760e39d9c4ec30
Author: Uwe Kleine-König <ukleinek@debian.org>
Date:   Fri Nov 22 08:56:05 2024 +0100

    ASoC: amd: yc: Add quirk for microphone on Lenovo Thinkpad T14s Gen 6 21M1CTO1WW
    
    [ Upstream commit cbc86dd0a4fe9f8c41075328c2e740b68419d639 ]
    
    Add a quirk for Tova's Lenovo Thinkpad T14s with product name 21M1.
    
    Suggested-by: Tova <blueaddagio@laposte.net>
    Link: https://bugs.debian.org/1087673
    Signed-off-by: Uwe Kleine-König <ukleinek@debian.org>
    Link: https://patch.msgid.link/20241122075606.213132-2-ukleinek@debian.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8ee41fc3522c6659e324d90bc2ccd3b6310d7fc
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Sat Nov 23 11:57:37 2024 +0800

    MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
    
    [ Upstream commit 4fbd66d8254cedfd1218393f39d83b6c07a01917 ]
    
    Fix the dtc warnings:
    
        arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
        arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
        arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
    
    And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on
    deprecated #address-cells/#size-cells handling"):
    
        WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
        Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
    
    The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe
    port nodes for ls7a"), which has fixed the issue for ls2k (despite its
    subject mentions ls7a).
    
    Signed-off-by: Xi Ruoyao <xry111@xry111.site>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b41d8adfd0f42ab6ca8e765838ec0adb2d445570
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Oct 24 22:05:12 2024 +0300

    iio: light: ltr501: Add LTER0303 to the supported devices
    
    [ Upstream commit c26acb09ccbef47d1fddaf0783c1392d0462122c ]
    
    It has been found that the (non-vendor issued) ACPI ID for Lite-On
    LTR303 is present in Microsoft catalog. Add it to the list of the
    supported devices.
    
    Link: https://www.catalog.update.microsoft.com/Search.aspx?q=lter0303
    Closes: https://lore.kernel.org/r/9cdda3e0-d56e-466f-911f-96ffd6f602c8@redhat.com
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://patch.msgid.link/20241024191200.229894-24-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af1d1d3e4e9a246a421aba49cb7bef6f4f8c06c1
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Thu Sep 26 10:29:04 2024 +0800

    usb: chipidea: udc: handle USB Error Interrupt if IOC not set
    
    [ Upstream commit 548f48b66c0c5d4b9795a55f304b7298cde2a025 ]
    
    As per USBSTS register description about UEI:
    
      When completion of a USB transaction results in an error condition, this
      bit is set by the Host/Device Controller. This bit is set along with the
      USBINT bit, if the TD on which the error interrupt occurred also had its
      interrupt on complete (IOC) bit set.
    
    UI is set only when IOC set. Add checking UEI to fix miss call
    isr_tr_complete_handler() when IOC have not set and transfer error happen.
    
    Acked-by: Peter Chen <peter.chen@kernel.com>
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20240926022906.473319-1-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08715b741f9b2a925d6485491e4907f3b29bac70
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Nov 22 15:47:48 2024 +0800

    LoongArch: Fix sleeping in atomic context for PREEMPT_RT
    
    [ Upstream commit 88fd2b70120d52c1010257d36776876941375490 ]
    
    Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in
    setup_tlb_handler()") changes the gfp flag from GFP_KERNEL to GFP_ATOMIC
    for alloc_pages_node(). However, for PREEMPT_RT kernels we can still get
    a "sleeping in atomic context" error:
    
    [    0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    [    0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
    [    0.372268] preempt_count: 1, expected: 0
    [    0.372270] RCU nest depth: 1, expected: 1
    [    0.372272] 3 locks held by swapper/1/0:
    [    0.372274]  #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60
    [    0.372294]  #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140
    [    0.372305]  #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0
    [    0.372314] irq event stamp: 0
    [    0.372316] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
    [    0.372322] hardirqs last disabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0
    [    0.372329] softirqs last  enabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0
    [    0.372335] softirqs last disabled at (0): [<0000000000000000>] 0x0
    [    0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891
    [    0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022
    [    0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000
    [    0.372486]         900000010038b890 0000000000000000 900000010038b898 9000000007e53788
    [    0.372492]         900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001
    [    0.372498]         0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0
    [    0.372503]         00000000000000c4 0000000000000001 000000000000002d 0000000000000003
    [    0.372509]         0000000000000030 0000000000000003 00000000055ec000 0000000000000003
    [    0.372515]         900000000806d000 9000000007e53788 00000000000000b0 0000000000000004
    [    0.372521]         0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000
    [    0.372526]         90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000
    [    0.372532]         00000000000000b0 0000000000000004 0000000000000000 0000000000070000
    [    0.372537]         ...
    [    0.372540] Call Trace:
    [    0.372542] [<9000000005924778>] show_stack+0x38/0x180
    [    0.372548] [<90000000071519c4>] dump_stack_lvl+0x94/0xe4
    [    0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260
    [    0.372561] [<90000000071675cc>] rt_spin_lock+0x4c/0x140
    [    0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0
    [    0.372570] [<9000000005cbed84>] get_page_from_freelist+0x564/0x1c60
    [    0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820
    [    0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298
    [    0.372585] [<9000000005924b74>] per_cpu_trap_init+0x114/0x140
    [    0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60
    [    0.372592] [<9000000005934874>] start_secondary+0x34/0xc0
    [    0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c
    
    This is because in PREEMPT_RT kernels normal spinlocks are replaced by
    rt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling
    NUMA optimization completely for PREEMPT_RT kernels.
    
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 816187b1833908941286e71b0041059a4acd52ed
Author: Defa Li <defa.li@mediatek.com>
Date:   Thu Nov 7 21:25:39 2024 +0800

    i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock
    
    [ Upstream commit 6cf7b65f7029914dc0cd7db86fac9ee5159008c6 ]
    
    A deadlock may happen since the i3c_master_register() acquires
    &i3cbus->lock twice. See the log below.
    Use i3cdev->desc->info instead of calling i3c_device_info() to
    avoid acquiring the lock twice.
    
    v2:
      - Modified the title and commit message
    
    ============================================
    WARNING: possible recursive locking detected
    6.11.0-mainline
    --------------------------------------------
    init/1 is trying to acquire lock:
    f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock
    
    but task is already holding lock:
    f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&i3cbus->lock);
      lock(&i3cbus->lock);
    
     *** DEADLOCK ***
    
     May be due to missing lock nesting notation
    
    2 locks held by init/1:
     #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach
     #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register
    
    stack backtrace:
    CPU: 6 UID: 0 PID: 1 Comm: init
    Call trace:
     dump_backtrace+0xfc/0x17c
     show_stack+0x18/0x28
     dump_stack_lvl+0x40/0xc0
     dump_stack+0x18/0x24
     print_deadlock_bug+0x388/0x390
     __lock_acquire+0x18bc/0x32ec
     lock_acquire+0x134/0x2b0
     down_read+0x50/0x19c
     i3c_bus_normaluse_lock+0x14/0x24
     i3c_device_get_info+0x24/0x58
     i3c_device_uevent+0x34/0xa4
     dev_uevent+0x310/0x384
     kobject_uevent_env+0x244/0x414
     kobject_uevent+0x14/0x20
     device_add+0x278/0x460
     device_register+0x20/0x34
     i3c_master_register_new_i3c_devs+0x78/0x154
     i3c_master_register+0x6a0/0x6d4
     mtk_i3c_master_probe+0x3b8/0x4d8
     platform_probe+0xa0/0xe0
     really_probe+0x114/0x454
     __driver_probe_device+0xa0/0x15c
     driver_probe_device+0x3c/0x1ac
     __driver_attach+0xc4/0x1f0
     bus_for_each_dev+0x104/0x160
     driver_attach+0x24/0x34
     bus_add_driver+0x14c/0x294
     driver_register+0x68/0x104
     __platform_driver_register+0x20/0x30
     init_module+0x20/0xfe4
     do_one_initcall+0x184/0x464
     do_init_module+0x58/0x1ec
     load_module+0xefc/0x10c8
     __arm64_sys_finit_module+0x238/0x33c
     invoke_syscall+0x58/0x10c
     el0_svc_common+0xa8/0xdc
     do_el0_svc+0x1c/0x28
     el0_svc+0x50/0xac
     el0t_64_sync_handler+0x70/0xbc
     el0t_64_sync+0x1a8/0x1ac
    
    Signed-off-by: Defa Li <defa.li@mediatek.com>
    Link: https://lore.kernel.org/r/20241107132549.25439-1-defa.li@mediatek.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d51345f75f61e710d063a5db625436bcf8f26f74
Author: Mengyuan Lou <mengyuanlou@net-swift.com>
Date:   Fri Nov 15 10:46:04 2024 +0800

    PCI: Add ACS quirk for Wangxun FF5xxx NICs
    
    [ Upstream commit aa46a3736afcb7b0793766d22479b8b99fc1b322 ]
    
    Wangxun FF5xxx NICs are similar to SFxxx, RP1000 and RP2000 NICs.  They may
    be multi-function devices, but they do not advertise an ACS capability.
    
    But the hardware does isolate FF5xxx functions as though it had an ACS
    capability and PCI_ACS_RR and PCI_ACS_CR were set in the ACS Control
    register, i.e., all peer-to-peer traffic is directed upstream instead of
    being routed internally.
    
    Add ACS quirk for FF5xxx NICs in pci_quirk_wangxun_nic_acs() so the
    functions can be in independent IOMMU groups.
    
    Link: https://lore.kernel.org/r/E16053DB2B80E9A5+20241115024604.30493-1-mengyuanlou@net-swift.com
    Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07911f83856a4673f7a8a90d4c01eb931e1d1bcb
Author: Keith Busch <kbusch@kernel.org>
Date:   Fri Oct 25 15:27:54 2024 -0700

    PCI: Add 'reset_subordinate' to reset hierarchy below bridge
    
    [ Upstream commit 2fa046449a82a7d0f6d9721dd83e348816038444 ]
    
    The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary
    Bus Reset on the bridge leading to the device.  These only work if the
    device is the only device below the bridge.
    
    Add a sysfs 'reset_subordinate' attribute on bridges that can assert
    Secondary Bus Reset regardless of how many devices are below the bridge.
    
    This resets all the devices below a bridge in a single command, including
    the locking and config space save/restore that reset methods normally do.
    
    This may be the only way to reset devices that don't support other reset
    methods (ACPI, FLR, PM reset, etc).
    
    Link: https://lore.kernel.org/r/20241025222755.3756162-1-kbusch@meta.com
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    [bhelgaas: commit log, add capable(CAP_SYS_ADMIN) check]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2dcaa24a007e3320ac60335455865ef0b01034cd
Author: Esther Shimanovich <eshimanovich@chromium.org>
Date:   Tue Sep 10 17:57:45 2024 +0000

    PCI: Detect and trust built-in Thunderbolt chips
    
    [ Upstream commit 3b96b895127b7c0aed63d82c974b46340e8466c1 ]
    
    Some computers with CPUs that lack Thunderbolt features use discrete
    Thunderbolt chips to add Thunderbolt functionality. These Thunderbolt
    chips are located within the chassis; between the Root Port labeled
    ExternalFacingPort and the USB-C port.
    
    These Thunderbolt PCIe devices should be labeled as fixed and trusted, as
    they are built into the computer. Otherwise, security policies that rely on
    those flags may have unintended results, such as preventing USB-C ports
    from enumerating.
    
    Detect the above scenario through the process of elimination.
    
      1) Integrated Thunderbolt host controllers already have Thunderbolt
         implemented, so anything outside their external facing Root Port is
         removable and untrusted.
    
         Detect them using the following properties:
    
           - Most integrated host controllers have the "usb4-host-interface"
             ACPI property, as described here:
    
             https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#mapping-native-protocols-pcie-displayport-tunneled-through-usb4-to-usb4-host-routers
    
           - Integrated Thunderbolt PCIe Root Ports before Alder Lake do not
             have the "usb4-host-interface" ACPI property. Identify those by
             their PCI IDs instead.
    
      2) If a Root Port does not have integrated Thunderbolt capabilities, but
         has the "ExternalFacingPort" ACPI property, that means the
         manufacturer has opted to use a discrete Thunderbolt host controller
         that is built into the computer.
    
         This host controller can be identified by virtue of being located
         directly below an external-facing Root Port that lacks integrated
         Thunderbolt. Label it as trusted and fixed.
    
         Everything downstream from it is untrusted and removable.
    
    The "ExternalFacingPort" ACPI property is described here:
    https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
    
    Link: https://lore.kernel.org/r/20240910-trust-tbt-fix-v5-1-7a7a42a5f496@chromium.org
    Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Esther Shimanovich <eshimanovich@chromium.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d745a56aea45e47f4755bc12e6429d6314dbb54
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date:   Fri Sep 20 17:44:31 2024 +0300

    i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request
    
    [ Upstream commit 6ca2738174e4ee44edb2ab2d86ce74f015a0cc32 ]
    
    Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when
    the ring is being stopped. Depending on timing between ring stop request
    completion, interrupt handler removal and code execution this may lead
    to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run
    after the io_data pointer is set to NULL in hci_dma_cleanup().
    
    Prevent this my masking the ring interrupts before ring stop request.
    
    Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Link: https://lore.kernel.org/r/20240920144432.62370-2-jarkko.nikula@linux.intel.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef517d2d21c3d8e2ad35b2bb728bd1c90a31e617
Author: Qi Han <hanqi@vivo.com>
Date:   Wed Sep 18 02:44:00 2024 -0600

    f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
    
    [ Upstream commit d5c367ef8287fb4d235c46a2f8c8d68715f3a0ca ]
    
    creating a large files during checkpoint disable until it runs out of
    space and then delete it, then remount to enable checkpoint again, and
    then unmount the filesystem triggers the f2fs_bug_on as below:
    
    ------------[ cut here ]------------
    kernel BUG at fs/f2fs/inode.c:896!
    CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    RIP: 0010:f2fs_evict_inode+0x58c/0x610
    Call Trace:
     __die_body+0x15/0x60
     die+0x33/0x50
     do_trap+0x10a/0x120
     f2fs_evict_inode+0x58c/0x610
     do_error_trap+0x60/0x80
     f2fs_evict_inode+0x58c/0x610
     exc_invalid_op+0x53/0x60
     f2fs_evict_inode+0x58c/0x610
     asm_exc_invalid_op+0x16/0x20
     f2fs_evict_inode+0x58c/0x610
     evict+0x101/0x260
     dispose_list+0x30/0x50
     evict_inodes+0x140/0x190
     generic_shutdown_super+0x2f/0x150
     kill_block_super+0x11/0x40
     kill_f2fs_super+0x7d/0x140
     deactivate_locked_super+0x2a/0x70
     cleanup_mnt+0xb3/0x140
     task_work_run+0x61/0x90
    
    The root cause is: creating large files during disable checkpoint
    period results in not enough free segments, so when writing back root
    inode will failed in f2fs_enable_checkpoint. When umount the file
    system after enabling checkpoint, the root inode is dirty in
    f2fs_evict_inode function, which triggers BUG_ON. The steps to
    reproduce are as follows:
    
    dd if=/dev/zero of=f2fs.img bs=1M count=55
    mount f2fs.img f2fs_dir -o checkpoint=disable:10%
    dd if=/dev/zero of=big bs=1M count=50
    sync
    rm big
    mount -o remount,checkpoint=enable f2fs_dir
    umount f2fs_dir
    
    Let's redirty inode when there is not free segments during checkpoint
    is disable.
    
    Signed-off-by: Qi Han <hanqi@vivo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6bdc332634f2992508d5118654532adca12b852
Author: Gabriele Monaco <gmonaco@redhat.com>
Date:   Thu Oct 17 08:42:39 2024 +0200

    verification/dot2: Improve dot parser robustness
    
    [ Upstream commit 571f8b3f866a6d990a50fe5c89fe0ea78784d70b ]
    
    This patch makes the dot parser used by dot2c and dot2k slightly more
    robust, namely:
    * allows parsing files with the gv extension (GraphViz)
    * correctly parses edges with any indentation
        * used to work only with a single character (e.g. '\t')
    Additionally it fixes a couple of warnings reported by pylint such as
    wrong indentation and comparison to False instead of `not ...`
    
    Link: https://lore.kernel.org/20241017064238.41394-2-gmonaco@redhat.com
    Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08f3ca17c16fe061c987cad4ad29649c6518d037
Author: Kees Cook <kees@kernel.org>
Date:   Sun Nov 17 03:32:09 2024 -0800

    smb: client: memcpy() with surrounding object base address
    
    [ Upstream commit f69b0187f8745a7a9584f6b13f5e792594b88b2e ]
    
    Like commit f1f047bd7ce0 ("smb: client: Fix -Wstringop-overflow issues"),
    adjust the memcpy() destination address to be based off the surrounding
    object rather than based off the 4-byte "Protocol" member. This avoids a
    build-time warning when compiling under CONFIG_FORTIFY_SOURCE with GCC 15:
    
    In function 'fortify_memcpy_chk',
        inlined from 'CIFSSMBSetPathInfo' at ../fs/smb/client/cifssmb.c:5358:2:
    ../include/linux/fortify-string.h:571:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
      571 |                         __write_overflow_field(p_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Kees Cook <kees@kernel.org>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12433c87d2c30a71c3bc352a9af53add5400c5e6
Author: Yi Yang <yiyang13@huawei.com>
Date:   Fri Nov 8 08:55:26 2024 +0000

    nvdimm: rectify the illogical code within nd_dax_probe()
    
    [ Upstream commit b61352101470f8b68c98af674e187cfaa7c43504 ]
    
    When nd_dax is NULL, nd_pfn is consequently NULL as well. Nevertheless,
    it is inadvisable to perform pointer arithmetic or address-taking on a
    NULL pointer.
    Introduce the nd_dax_devinit() function to enhance the code's logic and
    improve its readability.
    
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://patch.msgid.link/20241108085526.527957-1-yiyang13@huawei.com
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b859dd6702e1596a1d98628d6a9affc11d94c920
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>
Date:   Thu Oct 31 02:19:45 2024 +0100

    pinctrl: qcom: spmi-mpp: Add PM8937 compatible
    
    [ Upstream commit f755261190e88f5d19fe0a3b762f0bbaff6bd438 ]
    
    The PM8937 provides 4 MPPs.
    Add a compatible to support them.
    
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
    Link: https://lore.kernel.org/20241031-msm8917-v2-4-8a075faa89b1@mainlining.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cc16b146d7aad03e3a9a5d5915e72e7648b10bc
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>
Date:   Thu Oct 31 02:19:43 2024 +0100

    pinctrl: qcom-pmic-gpio: add support for PM8937
    
    [ Upstream commit 89265a58ff24e3885c2c9ca722bc3aaa47018be9 ]
    
    PM8937 has 8 GPIO-s with holes on GPIO3, GPIO4 and GPIO6.
    
    Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/20241031-msm8917-v2-2-8a075faa89b1@mainlining.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d63c36f0344387d90423f01be5137eb78081737
Author: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
Date:   Wed Nov 6 11:57:22 2024 +0200

    scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset
    
    [ Upstream commit 0b120edb37dc9dd8ca82893d386922eb6b16f860 ]
    
    Most drives rewind the tape when the device is reset. Reading and writing
    are not allowed until something is done to make the tape position match the
    user's expectation (e.g., rewind the tape). Add MTIOCGET and MTLOAD to
    operations allowed after reset. MTIOCGET is modified to not touch the tape
    if pos_unknown is non-zero. The tape location is known after MTLOAD.
    
    Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14
    Link: https://lore.kernel.org/r/20241106095723.63254-3-Kai.Makisara@kolumbus.fi
    Reviewed-by: John Meneghini <jmeneghi@redhat.com>
    Tested-by: John Meneghini <jmeneghi@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3ffc7769f80dd2aeabaaa4889b0c0746a7edca9
Author: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
Date:   Wed Nov 6 11:57:21 2024 +0200

    scsi: st: Don't modify unknown block number in MTIOCGET
    
    [ Upstream commit 5bb2d6179d1a8039236237e1e94cfbda3be1ed9e ]
    
    Struct mtget field mt_blkno -1 means it is unknown. Don't add anything to
    it.
    
    Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14
    Link: https://lore.kernel.org/r/20241106095723.63254-2-Kai.Makisara@kolumbus.fi
    Reviewed-by: John Meneghini <jmeneghi@redhat.com>
    Tested-by: John Meneghini <jmeneghi@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50d9f68e4adf86901cbab1bd5b91f710aa9141b9
Author: Mukesh Ojha <quic_mojha@quicinc.com>
Date:   Sun Nov 3 21:35:27 2024 +0530

    leds: class: Protect brightness_show() with led_cdev->led_access mutex
    
    [ Upstream commit 4ca7cd938725a4050dcd62ae9472e931d603118d ]
    
    There is NULL pointer issue observed if from Process A where hid device
    being added which results in adding a led_cdev addition and later a
    another call to access of led_cdev attribute from Process B can result
    in NULL pointer issue.
    
    Use mutex led_cdev->led_access to protect access to led->cdev and its
    attribute inside brightness_show() and max_brightness_show() and also
    update the comment for mutex that it should be used to protect the led
    class device fields.
    
            Process A                               Process B
    
     kthread+0x114
     worker_thread+0x244
     process_scheduled_works+0x248
     uhid_device_add_worker+0x24
     hid_add_device+0x120
     device_add+0x268
     bus_probe_device+0x94
     device_initial_probe+0x14
     __device_attach+0xfc
     bus_for_each_drv+0x10c
     __device_attach_driver+0x14c
     driver_probe_device+0x3c
     __driver_probe_device+0xa0
     really_probe+0x190
     hid_device_probe+0x130
     ps_probe+0x990
     ps_led_register+0x94
     devm_led_classdev_register_ext+0x58
     led_classdev_register_ext+0x1f8
     device_create_with_groups+0x48
     device_create_groups_vargs+0xc8
     device_add+0x244
     kobject_uevent+0x14
     kobject_uevent_env[jt]+0x224
     mutex_unlock[jt]+0xc4
     __mutex_unlock_slowpath+0xd4
     wake_up_q+0x70
     try_to_wake_up[jt]+0x48c
     preempt_schedule_common+0x28
     __schedule+0x628
     __switch_to+0x174
                                                    el0t_64_sync+0x1a8/0x1ac
                                                    el0t_64_sync_handler+0x68/0xbc
                                                    el0_svc+0x38/0x68
                                                    do_el0_svc+0x1c/0x28
                                                    el0_svc_common+0x80/0xe0
                                                    invoke_syscall+0x58/0x114
                                                    __arm64_sys_read+0x1c/0x2c
                                                    ksys_read+0x78/0xe8
                                                    vfs_read+0x1e0/0x2c8
                                                    kernfs_fop_read_iter+0x68/0x1b4
                                                    seq_read_iter+0x158/0x4ec
                                                    kernfs_seq_show+0x44/0x54
                                                    sysfs_kf_seq_show+0xb4/0x130
                                                    dev_attr_show+0x38/0x74
                                                    brightness_show+0x20/0x4c
                                                    dualshock4_led_get_brightness+0xc/0x74
    
    [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
    [ 3313.874301][ T4013] Mem abort info:
    [ 3313.874303][ T4013]   ESR = 0x0000000096000006
    [ 3313.874305][ T4013]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 3313.874307][ T4013]   SET = 0, FnV = 0
    [ 3313.874309][ T4013]   EA = 0, S1PTW = 0
    [ 3313.874311][ T4013]   FSC = 0x06: level 2 translation fault
    [ 3313.874313][ T4013] Data abort info:
    [ 3313.874314][ T4013]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
    [ 3313.874316][ T4013]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [ 3313.874318][ T4013]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000
    ..
    
    [ 3313.874332][ T4013] Dumping ftrace buffer:
    [ 3313.874334][ T4013]    (ftrace buffer empty)
    ..
    ..
    [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader
    [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74
    [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60
    [ 3313.874656][ T4013] sp : ffffffc0b910bbd0
    ..
    ..
    [ 3313.874685][ T4013] Call trace:
    [ 3313.874687][ T4013]  dualshock4_led_get_brightness+0xc/0x74
    [ 3313.874690][ T4013]  brightness_show+0x20/0x4c
    [ 3313.874692][ T4013]  dev_attr_show+0x38/0x74
    [ 3313.874696][ T4013]  sysfs_kf_seq_show+0xb4/0x130
    [ 3313.874700][ T4013]  kernfs_seq_show+0x44/0x54
    [ 3313.874703][ T4013]  seq_read_iter+0x158/0x4ec
    [ 3313.874705][ T4013]  kernfs_fop_read_iter+0x68/0x1b4
    [ 3313.874708][ T4013]  vfs_read+0x1e0/0x2c8
    [ 3313.874711][ T4013]  ksys_read+0x78/0xe8
    [ 3313.874714][ T4013]  __arm64_sys_read+0x1c/0x2c
    [ 3313.874718][ T4013]  invoke_syscall+0x58/0x114
    [ 3313.874721][ T4013]  el0_svc_common+0x80/0xe0
    [ 3313.874724][ T4013]  do_el0_svc+0x1c/0x28
    [ 3313.874727][ T4013]  el0_svc+0x38/0x68
    [ 3313.874730][ T4013]  el0t_64_sync_handler+0x68/0xbc
    [ 3313.874732][ T4013]  el0t_64_sync+0x1a8/0x1ac
    
    Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Reviewed-by: Anish Kumar <yesanishhere@gmail.com>
    Link: https://lore.kernel.org/r/20241103160527.82487-1-quic_mojha@quicinc.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e8a13f27e1f7805004485553fe6054d85183fd9
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Oct 18 12:47:39 2024 -0700

    scsi: ufs: core: Make DMA mask configuration more flexible
    
    [ Upstream commit 78bc671bd1501e2f6c571e063301a4fdc5db53b2 ]
    
    Replace UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS with
    ufs_hba_variant_ops::set_dma_mask.  Update the Renesas driver
    accordingly.  This patch enables supporting other configurations than
    32-bit or 64-bit DMA addresses, e.g. 36-bit DMA addresses.
    
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20241018194753.775074-1-bvanassche@acm.org
    Reviewed-by: Avri Altman <Avri.Altman@wdc.com>
    Reviewed-by: Peter Wang <peter.wang@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2991a023896b79e6753813ed88fbc98979713c73
Author: Yihang Li <liyihang9@huawei.com>
Date:   Tue Oct 8 10:18:16 2024 +0800

    scsi: hisi_sas: Add cond_resched() for no forced preemption model
    
    [ Upstream commit 2233c4a0b948211743659b24c13d6bd059fa75fc ]
    
    For no forced preemption model kernel, in the scenario where the
    expander is connected to 12 high performance SAS SSDs, the following
    call trace may occur:
    
    [  214.409199][  C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]
    [  214.568533][  C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
    [  214.575224][  C240] pc : fput_many+0x8c/0xdc
    [  214.579480][  C240] lr : fput+0x1c/0xf0
    [  214.583302][  C240] sp : ffff80002de2b900
    [  214.587298][  C240] x29: ffff80002de2b900 x28: ffff1082aa412000
    [  214.593291][  C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000
    [  214.599284][  C240] x25: ffff1062bbac5c40 x24: 0000000000001000
    [  214.605277][  C240] x23: 000000000000000a x22: 0000000000000001
    [  214.611270][  C240] x21: 0000000000001000 x20: 0000000000000000
    [  214.617262][  C240] x19: ffff3062a41ae580 x18: 0000000000010000
    [  214.623255][  C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0
    [  214.629248][  C240] x15: ffffffffffffffff x14: 0000000003ffffff
    [  214.635241][  C240] x13: 000000000000ffff x12: 000000000000029c
    [  214.641234][  C240] x11: 0000000000000006 x10: ffff80003a9f7fd0
    [  214.647226][  C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001
    [  214.653219][  C240] x7 : 0000000000000002 x6 : 0000000000000080
    [  214.659212][  C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554
    [  214.665205][  C240] x3 : 0000000000000002 x2 : 0000000000000020
    [  214.671198][  C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8
    [  214.677191][  C240] Call trace:
    [  214.680320][  C240]  fput_many+0x8c/0xdc
    [  214.684230][  C240]  fput+0x1c/0xf0
    [  214.687707][  C240]  aio_complete_rw+0xd8/0x1fc
    [  214.692225][  C240]  blkdev_bio_end_io+0x98/0x140
    [  214.696917][  C240]  bio_endio+0x160/0x1bc
    [  214.701001][  C240]  blk_update_request+0x1c8/0x3bc
    [  214.705867][  C240]  scsi_end_request+0x3c/0x1f0
    [  214.710471][  C240]  scsi_io_completion+0x7c/0x1a0
    [  214.715249][  C240]  scsi_finish_command+0x104/0x140
    [  214.720200][  C240]  scsi_softirq_done+0x90/0x180
    [  214.724892][  C240]  blk_mq_complete_request+0x5c/0x70
    [  214.730016][  C240]  scsi_mq_done+0x48/0xac
    [  214.734194][  C240]  sas_scsi_task_done+0xbc/0x16c [libsas]
    [  214.739758][  C240]  slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]
    [  214.746185][  C240]  cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]
    [  214.752179][  C240]  irq_thread_fn+0x34/0xa4
    [  214.756435][  C240]  irq_thread+0xc4/0x130
    [  214.760520][  C240]  kthread+0x108/0x13c
    [  214.764430][  C240]  ret_from_fork+0x10/0x18
    
    This is because in the hisi_sas driver, both the hardware interrupt
    handler and the interrupt thread are executed on the same CPU. In the
    performance test scenario, function irq_wait_for_interrupt() will always
    return 0 if lots of interrupts occurs and the CPU will be continuously
    consumed. As a result, the CPU cannot run the watchdog thread. When the
    watchdog time exceeds the specified time, call trace occurs.
    
    To fix it, add cond_resched() to execute the watchdog thread.
    
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Link: https://lore.kernel.org/r/20241008021822.2617339-8-liyihang9@huawei.com
    Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e5a4e8d1b871eac3e19bfbbb413906ab102416f
Author: Jan Stancek <jstancek@redhat.com>
Date:   Thu Oct 10 17:09:48 2024 +0200

    tools/rtla: fix collision with glibc sched_attr/sched_set_attr
    
    [ Upstream commit 0eecee340672c4b512f6f4a8c6add26df05d130c ]
    
    glibc commit 21571ca0d703 ("Linux: Add the sched_setattr
    and sched_getattr functions") now also provides 'struct sched_attr'
    and sched_setattr() which collide with the ones from rtla.
    
      In file included from src/trace.c:11:
      src/utils.h:49:8: error: redefinition of ‘struct sched_attr’
         49 | struct sched_attr {
            |        ^~~~~~~~~~
      In file included from /usr/include/bits/sched.h:60,
                       from /usr/include/sched.h:43,
                       from /usr/include/tracefs/tracefs.h:10,
                       from src/trace.c:4:
      /usr/include/linux/sched/types.h:98:8: note: originally defined here
         98 | struct sched_attr {
            |        ^~~~~~~~~~
    
    Define 'struct sched_attr' conditionally, similar to what strace did:
      https://lore.kernel.org/all/20240930222913.3981407-1-raj.khem@gmail.com/
    and rename rtla's version of sched_setattr() to avoid collision.
    
    Link: https://lore.kernel.org/8088f66a7a57c1b209cd8ae0ae7c336a7f8c930d.1728572865.git.jstancek@redhat.com
    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 943a0c5fa4bb2cdfbadd3c21f4ab245fc0fe0601
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Mon Oct 7 10:56:28 2024 +0200

    tracing: Use atomic64_inc_return() in trace_clock_counter()
    
    [ Upstream commit eb887c4567d1b0e7684c026fe7df44afa96589e6 ]
    
    Use atomic64_inc_return(&ref) instead of atomic64_add_return(1, &ref)
    to use optimized implementation and ease register pressure around
    the primitive for targets that implement optimized variant.
    
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Link: https://lore.kernel.org/20241007085651.48544-1-ubizjak@gmail.com
    Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69243255f2c68f48c43722d4a330935f64c0412b
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Tue Oct 8 21:07:12 2024 -0400

    tracing/ftrace: disable preemption in syscall probe
    
    [ Upstream commit 13d750c2c03e9861e15268574ed2c239cca9c9d5 ]
    
    In preparation for allowing system call enter/exit instrumentation to
    handle page faults, make sure that ftrace can handle this change by
    explicitly disabling preemption within the ftrace system call tracepoint
    probes to respect the current expectations within ftrace ring buffer
    code.
    
    This change does not yet allow ftrace to take page faults per se within
    its probe, but allows its existing probes to adapt to the upcoming
    change.
    
    Cc: Michael Jeanson <mjeanson@efficios.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
    Cc: bpf@vger.kernel.org
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Link: https://lore.kernel.org/20241009010718.2050182-3-mathieu.desnoyers@efficios.com
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9ca98ec1583876aa713049068ebc2cff30d2ead
Author: Esben Haabendal <esben@geanix.com>
Date:   Thu Oct 3 11:23:09 2024 +0200

    pinctrl: freescale: fix COMPILE_TEST error with PINCTRL_IMX_SCU
    
    [ Upstream commit 58414a31c5713afb5449fd74a26a843d34cc62e8 ]
    
    When PINCTRL_IMX_SCU was selected by PINCTRL_IMX8DXL or PINCTRL_IMX8QM
    combined with COMPILE_TEST on a non-arm platforms, the IMX_SCU
    dependency could not be enabled.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202410031439.GyTSa0kX-lkp@intel.com/
    Closes: https://lore.kernel.org/oe-kbuild-all/202410030852.q0Hukplf-lkp@intel.com/
    Signed-off-by: Esben Haabendal <esben@geanix.com>
    Link: https://lore.kernel.org/20241003-imx-pinctrl-compile-test-fix-v1-1-145ca1948cc3@geanix.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a16deb517a71243918f95f22c2c8730bc0f6579
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Nov 18 03:15:17 2024 -0800

    netpoll: Use rcu_access_pointer() in __netpoll_setup
    
    [ Upstream commit c69c5e10adb903ae2438d4f9c16eccf43d1fcbc1 ]
    
    The ndev->npinfo pointer in __netpoll_setup() is RCU-protected but is being
    accessed directly for a NULL check. While no RCU read lock is held in this
    context, we should still use proper RCU primitives for consistency and
    correctness.
    
    Replace the direct NULL check with rcu_access_pointer(), which is the
    appropriate primitive when only checking for NULL without dereferencing
    the pointer. This function provides the necessary ordering guarantees
    without requiring RCU read-side protection.
    
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Link: https://patch.msgid.link/20241118-netpoll_rcu-v1-1-a1888dcb4a02@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3100034a2d9e560d3f9693650a7551e270127a00
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Nov 14 16:32:21 2024 -0800

    net/neighbor: clear error in case strict check is not set
    
    [ Upstream commit 0de6a472c3b38432b2f184bd64eb70d9ea36d107 ]
    
    Commit 51183d233b5a ("net/neighbor: Update neigh_dump_info for strict
    data checking") added strict checking. The err variable is not cleared,
    so if we find no table to dump we will return the validation error even
    if user did not want strict checking.
    
    I think the only way to hit this is to send an buggy request, and ask
    for a table which doesn't exist, so there's no point treating this
    as a real fix. I only noticed it because a syzbot repro depended on it
    to trigger another bug.
    
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20241115003221.733593-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84e49db5b32645ea6fe429b98becdcfbb6fecf3f
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Thu Nov 14 18:19:46 2024 +0300

    rocker: fix link status detection in rocker_carrier_init()
    
    [ Upstream commit e64285ff41bb7a934bd815bd38f31119be62ac37 ]
    
    Since '1 << rocker_port->pport' may be undefined for port >= 32,
    cast the left operand to 'unsigned long long' like it's done in
    'rocker_port_set_enable()' above. Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Link: https://patch.msgid.link/20241114151946.519047-1-dmantipov@yandex.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c557ba8285a45869e143a699999d1f4ab632440
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Fri Nov 15 04:43:44 2024 +0000

    ASoC: hdmi-codec: reorder channel allocation list
    
    [ Upstream commit 82ff5abc2edcfba0c0f1a1be807795e2876f46e9 ]
    
    The ordering in hdmi_codec_get_ch_alloc_table_idx() results in
    wrong channel allocation for a number of cases, e.g. when ELD
    reports FL|FR|LFE|FC|RL|RR or FL|FR|LFE|FC|RL|RR|RC|RLC|RRC:
    
    ca_id 0x01 with speaker mask FL|FR|LFE is selected instead of
    ca_id 0x03 with speaker mask FL|FR|LFE|FC for 4 channels
    
    and
    
    ca_id 0x04 with speaker mask FL|FR|RC gets selected instead of
    ca_id 0x0b with speaker mask FL|FR|LFE|FC|RL|RR for 6 channels
    
    Fix this by reordering the channel allocation list with most
    specific speaker masks at the top.
    
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
    Link: https://patch.msgid.link/20241115044344.3510979-1-christianshewitt@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 559b1c7ac2e212a23b3833d3baf3bd957771d02e
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Oct 8 10:16:48 2024 -0400

    Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet
    
    [ Upstream commit 3fe288a8214e7dd784d1f9b7c9e448244d316b47 ]
    
    This fixes not checking if skb really contains an ACL header otherwise
    the code may attempt to access some uninitilized/invalid memory past the
    valid skb->data.
    
    Reported-by: syzbot+6ea290ba76d8c1eb1ac2@syzkaller.appspotmail.com
    Tested-by: syzbot+6ea290ba76d8c1eb1ac2@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=6ea290ba76d8c1eb1ac2
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2c3deaf2018601154f9e5ef0766159939cf1bc8
Author: Hilda Wu <hildawu@realtek.com>
Date:   Tue Oct 1 16:37:29 2024 +0800

    Bluetooth: btusb: Add RTL8852BE device 0489:e123 to device tables
    
    [ Upstream commit 69b84ffce260ff13826dc10aeb3c3e5c2288a552 ]
    
    Add the support ID 0489:e123 to usb_device_id table for
    Realtek RTL8852B chip.
    
    The device info from /sys/kernel/debug/usb/devices as below.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#=  7 Spd=12   MxCh= 0
    D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e123 Rev= 0.00
    S:  Manufacturer=Realtek
    S:  Product=Bluetooth Radio
    S:  SerialNumber=00e04c000001
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Hilda Wu <hildawu@realtek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d9a095160948b502dc39766e9a0173cd0ffedbb
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Sun Nov 10 18:59:55 2024 +0100

    dsa: qca8k: Use nested lock to avoid splat
    
    [ Upstream commit 078e0d596f7b5952dad8662ace8f20ed2165e2ce ]
    
    qca8k_phy_eth_command() is used to probe the child MDIO bus while the
    parent MDIO is locked. This causes lockdep splat, reporting a possible
    deadlock. It is not an actually deadlock, because different locks are
    used. By making use of mutex_lock_nested() we can avoid this false
    positive.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20241110175955.3053664-1-andrew@lunn.ch
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67a25ea28f8ec1da8894f2f115d01d3becf67dc7
Author: Norbert van Bolhuis <nvbolhuis@gmail.com>
Date:   Thu Nov 7 14:28:13 2024 +0100

    wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
    
    [ Upstream commit 857282b819cbaa0675aaab1e7542e2c0579f52d7 ]
    
    This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
    when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
    are sent from the pkt queue.
    
    The problem is the number of entries in the pre-allocated sgtable, it is
    nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.
    Given the default [rt]xglom_size=32 it's actually 35 which is too small.
    Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
    is added for each original SKB if tailroom isn't enough to hold tail_pad.
    At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
    in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
    NULL and this causes the oops.
    
    The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
    the worst-case.
    Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
    additional bytes of memory.
    
    Signed-off-by: Norbert van Bolhuis <nvbolhuis@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241107132903.13513-1-nvbolhuis@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4adc692826344b6759fa53adfda6c19d9b660cdc
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Fri Nov 1 14:07:25 2024 +0800

    wifi: ipw2x00: libipw_rx_any(): fix bad alignment
    
    [ Upstream commit 4fa4f049dc0d9741b16c96bcbf0108c85368a2b9 ]
    
    This patch fixes incorrect code alignment.
    
    ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:871:2-3: code aligned with following code on line 882.
    ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:886:2-3: code aligned with following code on line 900.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11381
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241101060725.54640-1-jiapeng.chong@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff0346a74627a5f607a33a3852586f8c7f678329
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Thu Oct 31 10:59:17 2024 +0800

    drm/amdgpu: set the right AMDGPU sg segment limitation
    
    [ Upstream commit e2e97435783979124ba92d6870415c57ecfef6a5 ]
    
    The driver needs to set the correct max_segment_size;
    otherwise debug_dma_map_sg() will complain about the
    over-mapping of the AMDGPU sg length as following:
    
    WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370
    [  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd
    [  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii
    [  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492
    [  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021
    [  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370
    [  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05
    [  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286
    [  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027
    [  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680
    [  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930
    [  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000
    [  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800
    [  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000
    [  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0
    [  364.049605] Call Trace:
    [  364.049607]  <TASK>
    [  364.049609]  ? show_regs+0x6d/0x80
    [  364.049614]  ? __warn+0x8c/0x140
    [  364.049618]  ? debug_dma_map_sg+0x2dc/0x370
    [  364.049621]  ? report_bug+0x193/0x1a0
    [  364.049627]  ? handle_bug+0x46/0x80
    [  364.049631]  ? exc_invalid_op+0x1d/0x80
    [  364.049635]  ? asm_exc_invalid_op+0x1f/0x30
    [  364.049642]  ? debug_dma_map_sg+0x2dc/0x370
    [  364.049647]  __dma_map_sg_attrs+0x90/0xe0
    [  364.049651]  dma_map_sgtable+0x25/0x40
    [  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu]
    [  364.049935]  ? srso_return_thunk+0x5/0x5f
    [  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]
    [  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm]
    [  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm]
    [  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]
    [  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]
    [  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]
    [  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu]
    [  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]
    [  364.051054]  ? srso_return_thunk+0x5/0x5f
    [  364.051057]  ? tomoyo_file_ioctl+0x20/0x30
    [  364.051063]  __x64_sys_ioctl+0x9c/0xd0
    [  364.051068]  x64_sys_call+0x1219/0x20d0
    [  364.051073]  do_syscall_64+0x51/0x120
    [  364.051077]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  364.051081] RIP: 0033:0x7fb2d2f1a94f
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 324a76b89f343a6e2d44b5787ea4617bba2d8e75
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 5 13:02:18 2024 +0100

    ALSA: usb-audio: Make mic volume workarounds globally applicable
    
    [ Upstream commit d6e6b9218ced5249b9136833ef5ec3f554ec7fde ]
    
    It seems that many webcams have buggy firmware and don't expose the
    mic capture volume with the proper resolution.  We have workarounds in
    mixer.c, but judging from the numbers, those can be better managed as
    global quirk flags.
    
    Link: https://patch.msgid.link/20241105120220.5740-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f014c96a127852579eb627f53ce5054ee6db9db
Author: Victor Zhao <Victor.Zhao@amd.com>
Date:   Thu Oct 24 13:40:39 2024 +0800

    drm/amdgpu: skip amdgpu_device_cache_pci_state under sriov
    
    [ Upstream commit afe260df55ac280cd56306248cb6d8a6b0db095c ]
    
    Under sriov, host driver will save and restore vf pci cfg space during
    reset. And during device init, under sriov, pci_restore_state happens after
    fullaccess released, and it can have race condition with mmio protection
    enable from host side leading to missing interrupts.
    
    So skip amdgpu_device_cache_pci_state for sriov.
    
    Signed-off-by: Victor Zhao <Victor.Zhao@amd.com>
    Acked-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 491487eeddccc4bb49f2e59d8c8f35bec89c15ca
Author: Nihar Chaithanya <niharchaithanya@gmail.com>
Date:   Wed Oct 9 01:51:38 2024 +0530

    jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree
    
    [ Upstream commit a174706ba4dad895c40b1d2277bade16dfacdcd9 ]
    
    When the value of lp is 0 at the beginning of the for loop, it will
    become negative in the next assignment and we should bail out.
    
    Reported-by: syzbot+412dea214d8baa3f7483@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=412dea214d8baa3f7483
    Tested-by: syzbot+412dea214d8baa3f7483@syzkaller.appspotmail.com
    Signed-off-by: Nihar Chaithanya <niharchaithanya@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff9fc48fab0e1ea0d423c23c99b91bba178f0b05
Author: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Date:   Tue Oct 1 11:35:47 2024 +0530

    jfs: fix array-index-out-of-bounds in jfs_readdir
    
    [ Upstream commit 839f102efb168f02dfdd46717b7c6dddb26b015e ]
    
    The stbl might contain some invalid values. Added a check to
    return error code in that case.
    
    Reported-by: syzbot+0315f8fe99120601ba88@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0315f8fe99120601ba88
    Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51a203470f502a64a3da8dcea51c4748e8267a6c
Author: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Date:   Mon Sep 30 13:42:18 2024 +0530

    jfs: fix shift-out-of-bounds in dbSplit
    
    [ Upstream commit a5f5e4698f8abbb25fe4959814093fb5bfa1aa9d ]
    
    When dmt_budmin is less than zero, it causes errors
    in the later stages. Added a check to return an error beforehand
    in dbAllocCtl itself.
    
    Reported-by: syzbot+b5ca8a249162c4b9a7d0@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=b5ca8a249162c4b9a7d0
    Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2eea5fda5556ef03defebf07b0a12fcd2c5210f4
Author: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Date:   Sat Sep 28 14:07:22 2024 +0530

    jfs: array-index-out-of-bounds fix in dtReadFirst
    
    [ Upstream commit ca84a2c9be482836b86d780244f0357e5a778c46 ]
    
    The value of stbl can be sometimes out of bounds due
    to a bad filesystem. Added a check with appopriate return
    of error code in that case.
    
    Reported-by: syzbot+65fa06e29859e41a83f3@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=65fa06e29859e41a83f3
    Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c1b4fea8d62285f5e1a8194889b39661608bd8a
Author: Levi Yun <yeoreum.yun@arm.com>
Date:   Fri Oct 25 11:06:00 2024 +0100

    dma-debug: fix a possible deadlock on radix_lock
    
    [ Upstream commit 7543c3e3b9b88212fcd0aaf5cab5588797bdc7de ]
    
    radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock
    otherwise, there's a possible deadlock scenario when
    dma debug API is called holding rq_lock():
    
    CPU0                   CPU1                       CPU2
    dma_free_attrs()
    check_unmap()          add_dma_entry()            __schedule() //out
                                                      (A) rq_lock()
    get_hash_bucket()
    (A) dma_entry_hash
                                                      check_sync()
                           (A) radix_lock()           (W) dma_entry_hash
    dma_entry_free()
    (W) radix_lock()
                           // CPU2's one
                           (W) rq_lock()
    
    CPU1 situation can happen when it extending radix tree and
    it tries to wake up kswapd via wake_all_kswapd().
    
    CPU2 situation can happen while perf_event_task_sched_out()
    (i.e. dma sync operation is called while deleting perf_event using
     etm and etr tmc which are Arm Coresight hwtracing driver backends).
    
    To remove this possible situation, call dma_entry_free() after
    put_hash_bucket() in check_unmap().
    
    Reported-by: Denis Nikitin <denik@chromium.org>
    Closes: https://lists.linaro.org/archives/list/coresight@lists.linaro.org/thread/2WMS7BBSF5OZYB63VT44U5YWLFP5HL6U/#RWM6MLQX5ANBTEQ2PRM7OXCBGCE6NPWU
    Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b295b197daf66d10474c21a5a48f13bc897cd523
Author: Lang Yu <lang.yu@amd.com>
Date:   Fri Oct 18 17:21:09 2024 +0800

    drm/amdgpu: refine error handling in amdgpu_ttm_tt_pin_userptr
    
    [ Upstream commit 46186667f98fb7158c98f4ff5da62c427761ffcd ]
    
    Free sg table when dma_map_sgtable() failed to avoid memory leak.
    
    Signed-off-by: Lang Yu <lang.yu@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ffd84c694c8f9da3bd2be320c6b84aba44a5233
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Thu Oct 17 14:54:31 2024 +0800

    drm/amdgpu: Dereference the ATCS ACPI buffer
    
    [ Upstream commit 32e7ee293ff476c67b51be006e986021967bc525 ]
    
    Need to dereference the atcs acpi buffer after
    the method is executed, otherwise it will result in
    a memory leak.
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 266a3354f782fe1da9c880e1069e4e39a7f7ef96
Author: Victor Lu <victorchengchi.lu@amd.com>
Date:   Thu Jul 18 18:01:23 2024 -0400

    drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts for vega20_ih
    
    [ Upstream commit 8b22f048331dfd45fdfbf0efdfb1d43deff7518d ]
    
    Port this change to vega20_ih.c:
    commit afbf7955ff01 ("drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts")
    
    Original commit message:
    "Why:
    Setting IH_RB_WPTR register to 0 will not clear the RB_OVERFLOW bit
    if RB_ENABLE is not set.
    
    How to fix:
    Set WPTR_OVERFLOW_CLEAR bit after RB_ENABLE bit is set.
    The RB_ENABLE bit is required to be set, together with
    WPTR_OVERFLOW_ENABLE bit so that setting WPTR_OVERFLOW_CLEAR bit
    would clear the RB_OVERFLOW."
    
    Signed-off-by: Victor Lu <victorchengchi.lu@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 166df51487f46b6e997dfeea7ca0c2a970853f07
Author: Philipp Stanner <pstanner@redhat.com>
Date:   Mon Oct 21 12:50:28 2024 +0200

    drm/sched: memset() 'job' in drm_sched_job_init()
    
    [ Upstream commit 2320c9e6a768d135c7b0039995182bb1a4e4fd22 ]
    
    drm_sched_job_init() has no control over how users allocate struct
    drm_sched_job. Unfortunately, the function can also not set some struct
    members such as job->sched.
    
    This could theoretically lead to UB by users dereferencing the struct's
    pointer members too early.
    
    It is easier to debug such issues if these pointers are initialized to
    NULL, so dereferencing them causes a NULL pointer exception.
    Accordingly, drm_sched_entity_init() does precisely that and initializes
    its struct with memset().
    
    Initialize parameter "job" to 0 in drm_sched_job_init().
    
    Signed-off-by: Philipp Stanner <pstanner@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241021105028.19794-2-pstanner@redhat.com
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 490f09dee85da1df7e1abe53f22e519032a2dd1d
Author: Shengyu Qu <wiagn233@outlook.com>
Date:   Sat Oct 12 01:39:17 2024 +0800

    net: sfp: change quirks for Alcatel Lucent G-010S-P
    
    [ Upstream commit 90cb5f1776ba371478e2b08fbf7018c7bd781a8d ]
    
    Seems Alcatel Lucent G-010S-P also have the same problem that it uses
    TX_FAULT pin for SOC uart. So apply sfp_fixup_ignore_tx_fault to it.
    
    Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
    Link: https://patch.msgid.link/TYCPR01MB84373677E45A7BFA5A28232C98792@TYCPR01MB8437.jpnprd01.prod.outlook.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b0161589ec0e7312ec114f5561225b461476ee9
Author: Manikandan Muralidharan <manikandan.m@microchip.com>
Date:   Thu Sep 19 14:45:48 2024 +0530

    drm/panel: simple: Add Microchip AC69T88A LVDS Display panel
    
    [ Upstream commit 40da1463cd6879f542238b36c1148f517927c595 ]
    
    Add support for Microchip AC69T88A 5 inch TFT LCD 800x480
    Display module with LVDS interface.The panel uses the Sitronix
    ST7262 800x480 Display driver
    
    Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
    Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240919091548.430285-2-manikandan.m@microchip.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18e450fc835dd30237864669a3fd7b2e6d466e66
Author: Rosen Penev <rosenp@gmail.com>
Date:   Mon Sep 30 11:07:16 2024 -0700

    wifi: ath5k: add PCI ID for Arcadyan devices
    
    [ Upstream commit f3ced9bb90b0a287a1fa6184d16b0f104a78fa90 ]
    
    Arcadyan made routers with this PCI ID containing an AR2417.
    
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Link: https://patch.msgid.link/20240930180716.139894-3-rosenp@gmail.com
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc871a02a5def7420bc7baa58fa1ffe416efab80
Author: Rosen Penev <rosenp@gmail.com>
Date:   Mon Sep 30 11:07:15 2024 -0700

    wifi: ath5k: add PCI ID for SX76X
    
    [ Upstream commit da0474012402d4729b98799d71a54c35dc5c5de3 ]
    
    This is in two devices made by Gigaset, SX762 and SX763.
    
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Link: https://patch.msgid.link/20240930180716.139894-2-rosenp@gmail.com
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79e16a0d339532ea832d85798eb036fc4f9e0cea
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:06 2024 +0100

    net: inet6: do not leave a dangling sk pointer in inet6_create()
    
    [ Upstream commit 9df99c395d0f55fb444ef39f4d6f194ca437d884 ]
    
    sock_init_data() attaches the allocated sk pointer to the provided sock
    object. If inet6_create() fails later, the sk object is released, but the
    sock object retains the dangling sk pointer, which may cause use-after-free
    later.
    
    Clear the sock sk pointer on error.
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-8-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4513cfd3a10c03c660d5d3d26c2e322efbfdd9b
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:05 2024 +0100

    net: inet: do not leave a dangling sk pointer in inet_create()
    
    [ Upstream commit 9365fa510c6f82e3aa550a09d0c5c6b44dbc78ff ]
    
    sock_init_data() attaches the allocated sk object to the provided sock
    object. If inet_create() fails later, the sk object is freed, but the
    sock object retains the dangling pointer, which may create use-after-free
    later.
    
    Clear the sk pointer in the sock object on error.
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-7-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8bd6c5f5dc2234b4ea714380aedeea12a781754
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:04 2024 +0100

    net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
    
    [ Upstream commit b4fcd63f6ef79c73cafae8cf4a114def5fc3d80d ]
    
    sock_init_data() attaches the allocated sk object to the provided sock
    object. If ieee802154_create() fails later, the allocated sk object is
    freed, but the dangling pointer remains in the provided sock object, which
    may allow use-after-free.
    
    Clear the sk pointer in the sock object on error.
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-6-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5947c9ac08f0771ea8ed64186b0d52e9029cb6c0
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:03 2024 +0100

    net: af_can: do not leave a dangling sk pointer in can_create()
    
    [ Upstream commit 811a7ca7320c062e15d0f5b171fe6ad8592d1434 ]
    
    On error can_create() frees the allocated sk object, but sock_init_data()
    has already attached it to the provided sock object. This will leave a
    dangling sk pointer in the sock object and may cause use-after-free later.
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Link: https://patch.msgid.link/20241014153808.51894-5-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac3eaac4cf142a15fe67be747a682b1416efeb6e
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:02 2024 +0100

    Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
    
    [ Upstream commit 3945c799f12b8d1f49a3b48369ca494d981ac465 ]
    
    bt_sock_alloc() attaches allocated sk object to the provided sock object.
    If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
    dangling pointer in the sock object, which may cause use-after-free.
    
    Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-4-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb2f2342a6ddf7c04f9aefbbfe86104cd138e629
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:01 2024 +0100

    Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
    
    [ Upstream commit 7c4f78cdb8e7501e9f92d291a7d956591bf73be9 ]
    
    bt_sock_alloc() allocates the sk object and attaches it to the provided
    sock object. On error l2cap_sock_alloc() frees the sk object, but the
    dangling pointer is still attached to the sock object, which may create
    use-after-free in other code.
    
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-3-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6cf750b737374454a4e03a5ed449a3eb0c96414
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Oct 14 16:38:00 2024 +0100

    af_packet: avoid erroring out after sock_init_data() in packet_create()
    
    [ Upstream commit 46f2a11cb82b657fd15bab1c47821b635e03838b ]
    
    After sock_init_data() the allocated sk object is attached to the provided
    sock object. On error, packet_create() frees the sk object leaving the
    dangling pointer in the sock object on return. Some other code may try
    to use this pointer and cause use-after-free.
    
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241014153808.51894-2-ignat@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a478f3841e6c2f17f4ede2c2bcf44864381f8bac
Author: Elena Salomatkina <esalomatkina@ispras.ru>
Date:   Sun Oct 13 15:45:29 2024 +0300

    net/sched: cbs: Fix integer overflow in cbs_set_port_rate()
    
    [ Upstream commit 397006ba5d918f9b74e734867e8fddbc36dc2282 ]
    
    The subsequent calculation of port_rate = speed * 1000 * BYTES_PER_KBIT,
    where the BYTES_PER_KBIT is of type LL, may cause an overflow.
    At least when speed = SPEED_20000, the expression to the left of port_rate
    will be greater than INT_MAX.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Elena Salomatkina <esalomatkina@ispras.ru>
    Link: https://patch.msgid.link/20241013124529.1043-1-esalomatkina@ispras.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c3d8ed72812449b70f0218e2612ce221d2179fd
Author: Simon Horman <horms@kernel.org>
Date:   Mon Oct 14 11:48:08 2024 +0100

    net: ethernet: fs_enet: Use %pa to format resource_size_t
    
    [ Upstream commit 45fe45fada261e1e83fce2a07fa22835aec1cf0a ]
    
    The correct format string for resource_size_t is %pa which
    acts on the address of the variable to be formatted [1].
    
    [1] https://elixir.bootlin.com/linux/v6.11.3/source/Documentation/core-api/printk-formats.rst#L229
    
    Introduced by commit 9d9326d3bc0e ("phy: Change mii_bus id field to a string")
    
    Flagged by gcc-14 as:
    
    drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c: In function 'fs_mii_bitbang_init':
    drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c:126:46: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Wformat=]
      126 |         snprintf(bus->id, MII_BUS_ID_SIZE, "%x", res.start);
          |                                             ~^   ~~~~~~~~~
          |                                              |      |
          |                                              |      resource_size_t {aka long long unsigned int}
          |                                              unsigned int
          |                                             %llx
    
    No functional change intended.
    Compile tested only.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Closes: https://lore.kernel.org/netdev/711d7f6d-b785-7560-f4dc-c6aad2cce99@linux-m68k.org/
    Signed-off-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
    Link: https://patch.msgid.link/20241014-net-pa-fmt-v1-2-dcc9afb8858b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab716f76664c545dd94a79f292405e3889f68f80
Author: Simon Horman <horms@kernel.org>
Date:   Mon Oct 14 11:48:07 2024 +0100

    net: fec_mpc52xx_phy: Use %pa to format resource_size_t
    
    [ Upstream commit 020bfdc4ed94be472138c891bde4d14241cf00fd ]
    
    The correct format string for resource_size_t is %pa which
    acts on the address of the variable to be formatted [1].
    
    [1] https://elixir.bootlin.com/linux/v6.11.3/source/Documentation/core-api/printk-formats.rst#L229
    
    Introduced by commit 9d9326d3bc0e ("phy: Change mii_bus id field to a string")
    
    Flagged by gcc-14 as:
    
    drivers/net/ethernet/freescale/fec_mpc52xx_phy.c: In function 'mpc52xx_fec_mdio_probe':
    drivers/net/ethernet/freescale/fec_mpc52xx_phy.c:97:46: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Wformat=]
       97 |         snprintf(bus->id, MII_BUS_ID_SIZE, "%x", res.start);
          |                                             ~^   ~~~~~~~~~
          |                                              |      |
          |                                              |      resource_size_t {aka long long unsigned int}
          |                                              unsigned int
          |                                             %llx
    
    No functional change intended.
    Compile tested only.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Closes: https://lore.kernel.org/netdev/711d7f6d-b785-7560-f4dc-c6aad2cce99@linux-m68k.org/
    Signed-off-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
    Link: https://patch.msgid.link/20241014-net-pa-fmt-v1-1-dcc9afb8858b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 039daf6f023935efb7edd786bce87e1698292ca0
Author: Zhu Jun <zhujun2@cmss.chinamobile.com>
Date:   Wed Oct 9 18:41:26 2024 -0700

    samples/bpf: Fix a resource leak
    
    [ Upstream commit f3ef53174b23246fe9bc2bbc2542f3a3856fa1e2 ]
    
    The opened file should be closed in show_sockopts(), otherwise resource
    leak will occur that this problem was discovered by reading code
    
    Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20241010014126.2573-1-zhujun2@cmss.chinamobile.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77f168247bfd0f8c6f73da4890e4d0a4f0ea4c74
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Oct 9 07:44:23 2024 +0200

    r8169: don't apply UDP padding quirk on RTL8126A
    
    [ Upstream commit 87e26448dbda4523b73a894d96f0f788506d3795 ]
    
    Vendor drivers r8125/r8126 indicate that this quirk isn't needed
    any longer for RTL8126A. Mimic this in r8169.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/d1317187-aa81-4a69-b831-678436e4de62@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5648abf72356357d00fa715d8cf82ff91901bca
Author: Brahmajit Das <brahmajit.xyz@gmail.com>
Date:   Wed Oct 2 14:53:11 2024 +0530

    drm/display: Fix building with GCC 15
    
    [ Upstream commit a500f3751d3c861be7e4463c933cf467240cca5d ]
    
    GCC 15 enables -Werror=unterminated-string-initialization by default.
    This results in the following build error
    
    drivers/gpu/drm/display/drm_dp_dual_mode_helper.c: In function ‘is_hdmi_adaptor’:
    drivers/gpu/drm/display/drm_dp_dual_mode_helper.c:164:17: error: initializer-string for array of
     ‘char’ is too long [-Werror=unterminated-string-initialization]
      164 |                 "DP-HDMI ADAPTOR\x04";
          |                 ^~~~~~~~~~~~~~~~~~~~~
    
    After discussion with Ville, the fix was to increase the size of
    dp_dual_mode_hdmi_id array by one, so that it can accommodate the NULL
    line character. This should let us build the kernel with GCC 15.
    
    Signed-off-by: Brahmajit Das <brahmajit.xyz@gmail.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241002092311.942822-1-brahmajit.xyz@gmail.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 578afcc9d9eb10a2c01f62b03cc83ebfc00fb8bd
Author: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
Date:   Fri Sep 27 18:07:19 2024 +0300

    drm/radeon/r600_cs: Fix possible int overflow in r600_packet3_check()
    
    [ Upstream commit a1e2da6a5072f8abe5b0feaa91a5bcd9dc544a04 ]
    
    It is possible, although unlikely, that an integer overflow will occur
    when the result of radeon_get_ib_value() is shifted to the left.
    
    Avoid it by casting one of the operands to larger data type (u64).
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Signed-off-by: Igor Artemiev <Igor.A.Artemiev@mcst.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f6165aec828cb421ded117d54850d73bfc73d7
Author: Liao Chen <liaochen4@huawei.com>
Date:   Mon Sep 2 11:33:20 2024 +0000

    drm/mcde: Enable module autoloading
    
    [ Upstream commit 8a16b5cdae26207ff4c22834559384ad3d7bc970 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
    on the alias from of_device_id table.
    
    Signed-off-by: Liao Chen <liaochen4@huawei.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240902113320.903147-4-liaochen4@huawei.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20baf71507dca437616b8f8600097520eec8be28
Author: Liao Chen <liaochen4@huawei.com>
Date:   Mon Sep 2 11:33:18 2024 +0000

    drm/bridge: it6505: Enable module autoloading
    
    [ Upstream commit 1e2ab24cd708b1c864ff983ee1504c0a409d2f8e ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
    on the alias from of_device_id table.
    
    Signed-off-by: Liao Chen <liaochen4@huawei.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240902113320.903147-2-liaochen4@huawei.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd376b0e6161f1beca7f474fe3892b4e9dc7b1e5
Author: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Date:   Mon Sep 16 15:18:55 2024 +0200

    drm: panel-orientation-quirks: Add quirk for AYA NEO GEEK
    
    [ Upstream commit 428656feb972ca99200fc127b5aecb574efd9d3d ]
    
    Add quirk orientation for AYA NEO GEEK. The name appears without
    spaces in DMI strings. The board name is completely different to
    the previous models making it difficult to reuse their quirks
    despite being the same resolution and using the same orientation.
    
    Tested by the JELOS team that has been patching their own kernel for a
    while now and confirmed by users in the AYA NEO and ChimeraOS discord
    servers.
    
    Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/40350b0d63fe2b54e7cba1e14be50917203f0079.1726492131.git.tjakobi@math.uni-bielefeld.de
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 719497a715e4d7960f8f672a244256b6f0bd1752
Author: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Date:   Mon Sep 16 15:18:53 2024 +0200

    drm: panel-orientation-quirks: Add quirk for AYA NEO Founder edition
    
    [ Upstream commit d7972d735ca80a40a571bf753c138263981a5698 ]
    
    Add quirk orientation for AYA NEO Founder. The name appears with spaces in
    DMI strings as other devices of the brand. The panel is the same as the
    NEXT and 2021 models. Those could not be reused as the former has VENDOR
    name as "AYANEO" without spaces and the latter has "AYADEVICE".
    
    Tested by the JELOS team that has been patching their own kernel for a
    while now and confirmed by users in the AYA NEO and ChimeraOS discord
    servers.
    
    Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/f71889a0b39f13f4b78481bd030377ca15035680.1726492131.git.tjakobi@math.uni-bielefeld.de
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dce37cb7f6f6384b2be93117865dfaa158d6d5d3
Author: Joaquín Ignacio Aramendía <samsagax@gmail.com>
Date:   Mon Sep 16 15:18:51 2024 +0200

    drm: panel-orientation-quirks: Add quirk for AYA NEO 2 model
    
    [ Upstream commit 361ebf5ef843b0aa1704c72eb26b91cf76c3c5b7 ]
    
    Add quirk orientation for AYA NEO 2. The name appears without spaces in
    DMI strings. That made it difficult to reuse the 2021 match. Also the
    display is larger in resolution.
    
    Tested by the JELOS team that has been patching their own kernel for a
    while now and confirmed by users in the AYA NEO and ChimeraOS discord
    servers.
    
    Signed-off-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/2b35545b77a9fd8c9699b751ca282226dcecb1dd.1726492131.git.tjakobi@math.uni-bielefeld.de
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09ba19adb990ac59d86b0d653ca4a434c11a3089
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Jun 21 16:20:30 2024 +0100

    drm/vc4: hvs: Set AXI panic modes for the HVS
    
    [ Upstream commit 014eccc9da7bfc76a3107fceea37dd60f1d63630 ]
    
    The HVS can change AXI request mode based on how full the COB
    FIFOs are.
    Until now the vc4 driver has been relying on the firmware to
    have set these to sensible values.
    
    With HVS channel 2 now being used for live video, change the
    panic mode for all channels to be explicitly set by the driver,
    and the same for all channels.
    
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-7-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 040299b28c1b62b79d8c31c381871de71db1ded5
Author: Dom Cobley <popcornmix@gmail.com>
Date:   Fri Jun 21 16:20:28 2024 +0100

    drm/vc4: hdmi: Avoid log spam for audio start failure
    
    [ Upstream commit b4e5646178e86665f5caef2894578600f597098a ]
    
    We regularly get dmesg error reports of:
    [   18.184066] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
    [   18.184098]  MAI: soc_pcm_open() failed (-19)
    
    These are generated for any disconnected hdmi interface when pulseaudio
    attempts to open the associated ALSA device (numerous times). Each open
    generates a kernel error message, generating general log spam.
    
    The error messages all come from _soc_pcm_ret in sound/soc/soc-pcm.c#L39
    which suggests returning ENOTSUPP, rather that ENODEV will be quiet.
    And indeed it is.
    
    Signed-off-by: Dom Cobley <popcornmix@gmail.com>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-5-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9459e166bc9f11bc6b3a507d81f6deb5bf972ad5
Author: Callahan Kovacs <callahankovacs@gmail.com>
Date:   Mon Nov 11 22:49:28 2024 +0100

    HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support
    
    [ Upstream commit 87a2f10395c82c2b4687bb8611a6c5663a12f9e7 ]
    
    Adds driver support for the USB-C model of Apple's Magic Trackpad 2.
    
    The 2024 USB-C model is compatible with the existing Magic Trackpad 2
    driver but has a different hardware ID.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219470
    Signed-off-by: Callahan Kovacs <callahankovacs@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea2ff66feb5f9b183f9e2f9d06c21340bd88de12
Author: Marek Vasut <marex@denx.de>
Date:   Sun Sep 29 20:49:16 2024 +0200

    soc: imx8m: Probe the SoC driver as platform driver
    
    [ Upstream commit 9cc832d37799dbea950c4c8a34721b02b8b5a8ff ]
    
    With driver_async_probe=* on kernel command line, the following trace is
    produced because on i.MX8M Plus hardware because the soc-imx8m.c driver
    calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock
    driver is not yet probed. This was not detected during regular testing
    without driver_async_probe.
    
    Convert the SoC code to platform driver and instantiate a platform device
    in its current device_initcall() to probe the platform driver. Rework
    .soc_revision callback to always return valid error code and return SoC
    revision via parameter. This way, if anything in the .soc_revision callback
    return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get
    retried later.
    
    "
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180
    CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603
    Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)
    pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : imx8mm_soc_revision+0xdc/0x180
    lr : imx8mm_soc_revision+0xd0/0x180
    sp : ffff8000821fbcc0
    x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120
    x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311
    x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb
    x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff
    x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8
    x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801
    x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c
    x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3
    x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000
    x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb
    Call trace:
     imx8mm_soc_revision+0xdc/0x180
     imx8_soc_init+0xb0/0x1e0
     do_one_initcall+0x94/0x1a8
     kernel_init_freeable+0x240/0x2a8
     kernel_init+0x28/0x140
     ret_from_fork+0x10/0x20
    ---[ end trace 0000000000000000 ]---
    SoC: i.MX8MP revision 1.1
    "
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8379d0cbd56c6e993a9dadbe6567c6b7ffcb844d
Author: Keita Aihara <keita.aihara@sony.com>
Date:   Fri Sep 13 18:44:17 2024 +0900

    mmc: core: Add SD card quirk for broken poweroff notification
    
    [ Upstream commit cd068d51594d9635bf6688fc78717572b78bce6a ]
    
    GIGASTONE Gaming Plus microSD cards manufactured on 02/2022 report that
    they support poweroff notification and cache, but they are not working
    correctly.
    
    Flush Cache bit never gets cleared in sd_flush_cache() and Poweroff
    Notification Ready bit also never gets set to 1 within 1 second from the
    end of busy of CMD49 in sd_poweroff_notify().
    
    This leads to I/O error and runtime PM error state.
    
    I observed that the same card manufactured on 01/2024 works as expected.
    
    This problem seems similar to the Kingston cards fixed with
    commit c467c8f08185 ("mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston
    Canvas Go Plus from 11/2019") and should be handled using quirks.
    
    CID for the problematic card is here.
    12345641535443002000000145016200
    
    Manufacturer ID is 0x12 and defined as CID_MANFID_GIGASTONE as of now,
    but would like comments on what naming is appropriate because MID list
    is not public and not sure it's right.
    
    Signed-off-by: Keita Aihara <keita.aihara@sony.com>
    Link: https://lore.kernel.org/r/20240913094417.GA4191647@sony.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8caec5e4a5f7354cb1fecd71729fd04f981d0aa9
Author: Rohan Barar <rohan.barar@gmail.com>
Date:   Thu Oct 3 19:40:40 2024 +1000

    media: cx231xx: Add support for Dexatek USB Video Grabber 1d19:6108
    
    [ Upstream commit 61a830bc0ea69a05d8a4534f825c6aa618263649 ]
    
    Add Dexatek Technology Ltd USB Video Grabber 1d19:6108 to the cx231xx
    driver. This device is sold under the name "BAUHN DVD Maker (DK8723)" by
    ALDI in Australia.
    
    This device is similar to 1d19:6109, which is already included in cx231xx.
    
    Both video and audio capture function correctly after installing the
    patched cx231xx driver.
    
    Patch Changelog
    v1:
     - Initial submission.
    v2:
     - Fix SoB + Improve subject.
    v3:
     - Rephrase message to not exceed 75 characters per line.
     - Removed reference to external GitHub URL.
    
    Signed-off-by: Rohan Barar <rohan.barar@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 467d2d7ccb36219feeb121c08a2e3d0a6aa8808f
Author: David Given <dg@cowlark.com>
Date:   Wed Sep 18 20:05:40 2024 +0200

    media: uvcvideo: Add a quirk for the Kaiweets KTI-W02 infrared camera
    
    [ Upstream commit b2ec92bb5605452d539a7aa1e42345b95acd8583 ]
    
    Adds a quirk to make the NXP Semiconductors 1fc9:009b chipset work.
    
    lsusb for the device reports:
    
    Bus 003 Device 011: ID 1fc9:009b NXP Semiconductors IR VIDEO
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass          239 Miscellaneous Device
      bDeviceSubClass         2 [unknown]
      bDeviceProtocol         1 Interface Association
      bMaxPacketSize0        64
      idVendor           0x1fc9 NXP Semiconductors
      idProduct          0x009b IR VIDEO
      bcdDevice            1.01
      iManufacturer           1 Guide sensmart
      iProduct                2 IR VIDEO
      iSerial                 0
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength       0x00c2
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0xc0
          Self Powered
        MaxPower              100mA
        Interface Association:
          bLength                 8
          bDescriptorType        11
          bFirstInterface         0
          bInterfaceCount         2
          bFunctionClass         14 Video
          bFunctionSubClass       3 Video Interface Collection
          bFunctionProtocol       0
          iFunction               3 IR Camera
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass        14 Video
          bInterfaceSubClass      1 Video Control
          bInterfaceProtocol      0
          iInterface              0
          VideoControl Interface Descriptor:
            bLength                13
            bDescriptorType        36
            bDescriptorSubtype      1 (HEADER)
            bcdUVC               1.00
            wTotalLength       0x0033
            dwClockFrequency        6.000000MHz
            bInCollection           1
            baInterfaceNr( 0)       1
          VideoControl Interface Descriptor:
            bLength                18
            bDescriptorType        36
            bDescriptorSubtype      2 (INPUT_TERMINAL)
            bTerminalID             1
            wTerminalType      0x0201 Camera Sensor
            bAssocTerminal          0
            iTerminal               0
            wObjectiveFocalLengthMin      0
            wObjectiveFocalLengthMax      0
            wOcularFocalLength            0
            bControlSize                  3
            bmControls           0x00000000
          VideoControl Interface Descriptor:
            bLength                 9
            bDescriptorType        36
            bDescriptorSubtype      3 (OUTPUT_TERMINAL)
            bTerminalID             2
            wTerminalType      0x0101 USB Streaming
            bAssocTerminal          0
            bSourceID               1
            iTerminal               0
          VideoControl Interface Descriptor:
            bLength                11
            bDescriptorType        36
            bDescriptorSubtype      5 (PROCESSING_UNIT)
          Warning: Descriptor too short
            bUnitID                 3
            bSourceID               1
            wMaxMultiplier          0
            bControlSize            2
            bmControls     0x00000000
            iProcessing             0
            bmVideoStandards     0x62
              NTSC - 525/60
              PAL - 525/60
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0008  1x 8 bytes
            bInterval               1
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           0
          bInterfaceClass        14 Video
          bInterfaceSubClass      2 Video Streaming
          bInterfaceProtocol      0
          iInterface              0
          VideoStreaming Interface Descriptor:
            bLength                            14
            bDescriptorType                    36
            bDescriptorSubtype                  1 (INPUT_HEADER)
            bNumFormats                         1
            wTotalLength                   0x0055
            bEndpointAddress                 0x82  EP 2 IN
            bmInfo                              0
            bTerminalLink                       2
            bStillCaptureMethod                 2
            bTriggerSupport                     0
            bTriggerUsage                       0
            bControlSize                        1
            bmaControls( 0)                     0
          VideoStreaming Interface Descriptor:
            bLength                            27
            bDescriptorType                    36
            bDescriptorSubtype                  4 (FORMAT_UNCOMPRESSED)
            bFormatIndex                        1
            bNumFrameDescriptors                1
            guidFormat                            {e436eb7b-524f-11ce-9f53-0020af0ba770}
            bBitsPerPixel                      16
            bDefaultFrameIndex                  1
            bAspectRatioX                       0
            bAspectRatioY                       0
            bmInterlaceFlags                 0x00
              Interlaced stream or variable: No
              Fields per frame: 2 fields
              Field 1 first: No
              Field pattern: Field 1 only
            bCopyProtect                        0
          VideoStreaming Interface Descriptor:
            bLength                            34
            bDescriptorType                    36
            bDescriptorSubtype                  5 (FRAME_UNCOMPRESSED)
            bFrameIndex                         1
            bmCapabilities                   0x00
              Still image unsupported
            wWidth                            240
            wHeight                           322
            dwMinBitRate                 12364800
            dwMaxBitRate                 30912000
            dwMaxVideoFrameBufferSize      154560
            dwDefaultFrameInterval         400000
            bFrameIntervalType                  2
            dwFrameInterval( 0)            400000
            dwFrameInterval( 1)           1000000
          VideoStreaming Interface Descriptor:
            bLength                            10
            bDescriptorType                    36
            bDescriptorSubtype                  3 (STILL_IMAGE_FRAME)
            bEndpointAddress                 0x00  EP 0 OUT
            bNumImageSizePatterns               1
            wWidth( 0)                        240
            wHeight( 0)                       322
            bNumCompressionPatterns             0
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       1
          bNumEndpoints           1
          bInterfaceClass        14 Video
          bInterfaceSubClass      2 Video Streaming
          bInterfaceProtocol      0
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x82  EP 2 IN
            bmAttributes            5
              Transfer Type            Isochronous
              Synch Type               Asynchronous
              Usage Type               Data
            wMaxPacketSize     0x0400  1x 1024 bytes
            bInterval               1
    Device Status:     0x0001
      Self Powered
    
    Signed-off-by: David Given <dg@cowlark.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Link: https://lore.kernel.org/r/20240918180540.10830-2-dg@cowlark.com
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b36192357c3a8d524a199dacfc0531f4d048e13
Author: Breno Leitao <leitao@debian.org>
Date:   Tue Oct 1 07:10:19 2024 -0700

    perf/x86/amd: Warn only on new bits set
    
    [ Upstream commit de20037e1b3c2f2ca97b8c12b8c7bca8abd509a7 ]
    
    Warning at every leaking bits can cause a flood of message, triggering
    various stall-warning mechanisms to fire, including CSD locks, which
    makes the machine to be unusable.
    
    Track the bits that are being leaked, and only warn when a new bit is
    set.
    
    That said, this patch will help with the following issues:
    
    1) It will tell us which bits are being set, so, it is easy to
       communicate it back to vendor, and to do a root-cause analyzes.
    
    2) It avoid the machine to be unusable, because, worst case
       scenario, the user gets less than 60 WARNs (one per unhandled bit).
    
    Suggested-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Sandipan Das <sandipan.das@amd.com>
    Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
    Link: https://lkml.kernel.org/r/20241001141020.2620361-1-leitao@debian.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ab4951c1473c7d1ceaf1232eb927109cd1c4859
Author: Marco Elver <elver@google.com>
Date:   Tue Oct 1 16:00:45 2024 +0200

    kcsan: Turn report_filterlist_lock into a raw_spinlock
    
    [ Upstream commit 59458fa4ddb47e7891c61b4a928d13d5f5b00aa0 ]
    
    Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see
    splats like:
    
    | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
    | preempt_count: 10002, expected: 0
    | RCU nest depth: 0, expected: 0
    | no locks held by swapper/1/0.
    | irq event stamp: 156674
    | hardirqs last  enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240
    | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0
    | softirqs last  enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60
    | softirqs last disabled at (0): [<0000000000000000>] 0x0
    | Preemption disabled at:
    | [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90
    | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3
    | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
    | Call Trace:
    |  <IRQ>
    |  dump_stack_lvl+0x7e/0xc0
    |  dump_stack+0x1d/0x30
    |  __might_resched+0x1a2/0x270
    |  rt_spin_lock+0x68/0x170
    |  kcsan_skip_report_debugfs+0x43/0xe0
    |  print_report+0xb5/0x590
    |  kcsan_report_known_origin+0x1b1/0x1d0
    |  kcsan_setup_watchpoint+0x348/0x650
    |  __tsan_unaligned_write1+0x16d/0x1d0
    |  hrtimer_interrupt+0x3d6/0x430
    |  __sysvec_apic_timer_interrupt+0xe8/0x3a0
    |  sysvec_apic_timer_interrupt+0x97/0xc0
    |  </IRQ>
    
    On a detected data race, KCSAN's reporting logic checks if it should
    filter the report. That list is protected by the report_filterlist_lock
    *non-raw* spinlock which may sleep on RT kernels.
    
    Since KCSAN may report data races in any context, convert it to a
    raw_spinlock.
    
    This requires being careful about when to allocate memory for the filter
    list itself which can be done via KCSAN's debugfs interface. Concurrent
    modification of the filter list via debugfs should be rare: the chosen
    strategy is to optimistically pre-allocate memory before the critical
    section and discard if unused.
    
    Link: https://lore.kernel.org/all/20240925143154.2322926-1-ranxiaokai627@163.com/
    Reported-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
    Tested-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
    Signed-off-by: Marco Elver <elver@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c0027dc17dd1720e9358e5d29569ca3e309e5c8
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Nov 11 16:18:55 2024 +0000

    kselftest/arm64: Don't leak pipe fds in pac.exec_sign_all()
    
    [ Upstream commit 27141b690547da5650a420f26ec369ba142a9ebb ]
    
    The PAC exec_sign_all() test spawns some child processes, creating pipes
    to be stdin and stdout for the child. It cleans up most of the file
    descriptors that are created as part of this but neglects to clean up the
    parent end of the child stdin and stdout. Add the missing close() calls.
    
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20241111-arm64-pac-test-collisions-v1-1-171875f37e44@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcea29dff6f2f2ad6f4079cd1efa215fb719ef3e
Author: Boris Burkov <boris@bur.io>
Date:   Tue Oct 15 14:27:32 2024 -0700

    btrfs: do not clear read-only when adding sprout device
    
    [ Upstream commit 70958a949d852cbecc3d46127bf0b24786df0130 ]
    
    If you follow the seed/sprout wiki, it suggests the following workflow:
    
    btrfstune -S 1 seed_dev
    mount seed_dev mnt
    btrfs device add sprout_dev
    mount -o remount,rw mnt
    
    The first mount mounts the FS readonly, which results in not setting
    BTRFS_FS_OPEN, and setting the readonly bit on the sb. The device add
    somewhat surprisingly clears the readonly bit on the sb (though the
    mount is still practically readonly, from the users perspective...).
    Finally, the remount checks the readonly bit on the sb against the flag
    and sees no change, so it does not run the code intended to run on
    ro->rw transitions, leaving BTRFS_FS_OPEN unset.
    
    As a result, when the cleaner_kthread runs, it sees no BTRFS_FS_OPEN and
    does no work. This results in leaking deleted snapshots until we run out
    of space.
    
    I propose fixing it at the first departure from what feels reasonable:
    when we clear the readonly bit on the sb during device add.
    
    A new fstest I have written reproduces the bug and confirms the fix.
    
    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: Sasha Levin <sashal@kernel.org>

commit 72c49143fb9087e4d324846d4e8dec2069dd2f46
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Sep 24 12:52:17 2024 +0930

    btrfs: avoid unnecessary device path update for the same device
    
    [ Upstream commit 2e8b6bc0ab41ce41e6dfcc204b6cc01d5abbc952 ]
    
    [PROBLEM]
    It is very common for udev to trigger device scan, and every time a
    mounted btrfs device got re-scan from different soft links, we will get
    some of unnecessary device path updates, this is especially common
    for LVM based storage:
    
     # lvs
      scratch1 test -wi-ao---- 10.00g
      scratch2 test -wi-a----- 10.00g
      scratch3 test -wi-a----- 10.00g
      scratch4 test -wi-a----- 10.00g
      scratch5 test -wi-a----- 10.00g
      test     test -wi-a----- 10.00g
    
     # mkfs.btrfs -f /dev/test/scratch1
     # mount /dev/test/scratch1 /mnt/btrfs
     # dmesg -c
     [  205.705234] BTRFS: device fsid 7be2602f-9e35-4ecf-a6ff-9e91d2c182c9 devid 1 transid 6 /dev/mapper/test-scratch1 (253:4) scanned by mount (1154)
     [  205.710864] BTRFS info (device dm-4): first mount of filesystem 7be2602f-9e35-4ecf-a6ff-9e91d2c182c9
     [  205.711923] BTRFS info (device dm-4): using crc32c (crc32c-intel) checksum algorithm
     [  205.713856] BTRFS info (device dm-4): using free-space-tree
     [  205.722324] BTRFS info (device dm-4): checking UUID tree
    
    So far so good, but even if we just touched any soft link of
    "dm-4", we will get quite some unnecessary device path updates.
    
     # touch /dev/mapper/test-scratch1
     # dmesg -c
     [  469.295796] BTRFS info: devid 1 device path /dev/mapper/test-scratch1 changed to /dev/dm-4 scanned by (udev-worker) (1221)
     [  469.300494] BTRFS info: devid 1 device path /dev/dm-4 changed to /dev/mapper/test-scratch1 scanned by (udev-worker) (1221)
    
    Such device path rename is unnecessary and can lead to random path
    change due to the udev race.
    
    [CAUSE]
    Inside device_list_add(), we are using a very primitive way checking if
    the device has changed, strcmp().
    
    Which can never handle links well, no matter if it's hard or soft links.
    
    So every different link of the same device will be treated as a different
    device, causing the unnecessary device path update.
    
    [FIX]
    Introduce a helper, is_same_device(), and use path_equal() to properly
    detect the same block device.
    So that the different soft links won't trigger the rename race.
    
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1230641
    Reported-by: Fabian Vogt <fvogt@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5be6a0bb639d165c8418d8dddd8f322587be8be
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Fri Oct 25 12:27:53 2024 +0200

    s390/cpum_sf: Handle CPU hotplug remove during sampling
    
    [ Upstream commit a0bd7dacbd51c632b8e2c0500b479af564afadf3 ]
    
    CPU hotplug remove handling triggers the following function
    call sequence:
    
       CPUHP_AP_PERF_S390_SF_ONLINE  --> s390_pmu_sf_offline_cpu()
       ...
       CPUHP_AP_PERF_ONLINE          --> perf_event_exit_cpu()
    
    The s390 CPUMF sampling CPU hotplug handler invokes:
    
     s390_pmu_sf_offline_cpu()
     +-->  cpusf_pmu_setup()
           +--> setup_pmc_cpu()
                +--> deallocate_buffers()
    
    This function de-allocates all sampling data buffers (SDBs) allocated
    for that CPU at event initialization. It also clears the
    PMU_F_RESERVED bit. The CPU is gone and can not be sampled.
    
    With the event still being active on the removed CPU, the CPU event
    hotplug support in kernel performance subsystem triggers the
    following function calls on the removed CPU:
    
      perf_event_exit_cpu()
      +--> perf_event_exit_cpu_context()
           +--> __perf_event_exit_context()
                +--> __perf_remove_from_context()
                     +--> event_sched_out()
                          +--> cpumsf_pmu_del()
                               +--> cpumsf_pmu_stop()
                                    +--> hw_perf_event_update()
    
    to stop and remove the event. During removal of the event, the
    sampling device driver tries to read out the remaining samples from
    the sample data buffers (SDBs). But they have already been freed
    (and may have been re-assigned). This may lead to a use after free
    situation in which case the samples are most likely invalid. In the
    best case the memory has not been reassigned and still contains
    valid data.
    
    Remedy this situation and check if the CPU is still in reserved
    state (bit PMU_F_RESERVED set). In this case the SDBs have not been
    released an contain valid data. This is always the case when
    the event is removed (and no CPU hotplug off occured).
    If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.
    
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 670fc6d14f1076152553c2805437fd11860562df
Author: Christian Brauner <brauner@kernel.org>
Date:   Wed Sep 25 11:05:16 2024 +0200

    epoll: annotate racy check
    
    [ Upstream commit 6474353a5e3d0b2cf610153cea0c61f576a36d0a ]
    
    Epoll relies on a racy fastpath check during __fput() in
    eventpoll_release() to avoid the hit of pointlessly acquiring a
    semaphore. Annotate that race by using WRITE_ONCE() and READ_ONCE().
    
    Link: https://lore.kernel.org/r/66edfb3c.050a0220.3195df.001a.GAE@google.com
    Link: https://lore.kernel.org/r/20240925-fungieren-anbauen-79b334b00542@brauner
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reported-by: syzbot+3b6b32dc50537a49bb4a@syzkaller.appspotmail.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8f794f387ad21c4696e5cd0626cb6f8a5f6aea5
Author: Pratyush Brahma <quic_pbrahma@quicinc.com>
Date:   Fri Oct 4 14:34:28 2024 +0530

    iommu/arm-smmu: Defer probe of clients after smmu device bound
    
    commit 229e6ee43d2a160a1592b83aad620d6027084aad upstream.
    
    Null pointer dereference occurs due to a race between smmu
    driver probe and client driver probe, when of_dma_configure()
    for client is called after the iommu_device_register() for smmu driver
    probe has executed but before the driver_bound() for smmu driver
    has been called.
    
    Following is how the race occurs:
    
    T1:Smmu device probe            T2: Client device probe
    
    really_probe()
    arm_smmu_device_probe()
    iommu_device_register()
                                            really_probe()
                                            platform_dma_configure()
                                            of_dma_configure()
                                            of_dma_configure_id()
                                            of_iommu_configure()
                                            iommu_probe_device()
                                            iommu_init_device()
                                            arm_smmu_probe_device()
                                            arm_smmu_get_by_fwnode()
                                                    driver_find_device_by_fwnode()
                                                    driver_find_device()
                                                    next_device()
                                                    klist_next()
                                                        /* null ptr
                                                           assigned to smmu */
                                            /* null ptr dereference
                                               while smmu->streamid_mask */
    driver_bound()
            klist_add_tail()
    
    When this null smmu pointer is dereferenced later in
    arm_smmu_probe_device, the device crashes.
    
    Fix this by deferring the probe of the client device
    until the smmu device has bound to the arm smmu driver.
    
    Fixes: 021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
    Cc: stable@vger.kernel.org
    Co-developed-by: Prakash Gupta <quic_guptap@quicinc.com>
    Signed-off-by: Prakash Gupta <quic_guptap@quicinc.com>
    Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
    Link: https://lore.kernel.org/r/20241004090428.2035-1-quic_pbrahma@quicinc.com
    [will: Add comment]
    Signed-off-by: Will Deacon <will@kernel.org>
    [rm: backport for context conflict prior to 6.8]
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 254abd3d87de994ccd1de15799a0d84c10113930
Author: Kees Cook <kees@kernel.org>
Date:   Sun Nov 17 03:38:13 2024 -0800

    lib: stackinit: hide never-taken branch from compiler
    
    commit 5c3793604f91123bf49bc792ce697a0bef4c173c upstream.
    
    The never-taken branch leads to an invalid bounds condition, which is by
    design. To avoid the unwanted warning from the compiler, hide the
    variable from the optimizer.
    
    ../lib/stackinit_kunit.c: In function 'do_nothing_u16_zero':
    ../lib/stackinit_kunit.c:51:49: error: array subscript 1 is outside array bounds of 'u16[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds=]
       51 | #define DO_NOTHING_RETURN_SCALAR(ptr)           *(ptr)
          |                                                 ^~~~~~
    ../lib/stackinit_kunit.c:219:24: note: in expansion of macro 'DO_NOTHING_RETURN_SCALAR'
      219 |                 return DO_NOTHING_RETURN_ ## which(ptr + 1);    \
          |                        ^~~~~~~~~~~~~~~~~~
    
    Link: https://lkml.kernel.org/r/20241117113813.work.735-kees@kernel.org
    Signed-off-by: Kees Cook <kees@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5411aaa1d8b01f090b62b55001fbe8ae854d3109
Author: Wengang Wang <wen.gang.wang@oracle.com>
Date:   Tue Nov 19 09:45:00 2024 -0800

    ocfs2: update seq_file index in ocfs2_dlm_seq_next
    
    commit 914eec5e980171bc128e7e24f7a22aa1d803570e upstream.
    
    The following INFO level message was seen:
    
    seq_file: buggy .next function ocfs2_dlm_seq_next [ocfs2] did not
    update position index
    
    Fix:
    Update *pos (so m->index) to make seq_read_iter happy though the index its
    self makes no sense to ocfs2_dlm_seq_next.
    
    Link: https://lkml.kernel.org/r/20241119174500.9198-1-wen.gang.wang@oracle.com
    Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74eb8dd0c5abe2086dd876fe9e35b0ef9b8a37c1
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Mon Nov 25 13:24:46 2024 +0100

    mmc: core: Further prevent card detect during shutdown
    
    commit 87a0d90fcd31c0f36da0332428c9e1a1e0f97432 upstream.
    
    Disabling card detect from the host's ->shutdown_pre() callback turned out
    to not be the complete solution. More precisely, beyond the point when the
    mmc_bus->shutdown() has been called, to gracefully power off the card, we
    need to prevent card detect. Otherwise the mmc_rescan work may poll for the
    card with a CMD13, to see if it's still alive, which then will fail and
    hang as the card has already been powered off.
    
    To fix this problem, let's disable mmc_rescan prior to power off the card
    during shutdown.
    
    Reported-by: Anthony Pighin <anthony.pighin@nokia.com>
    Fixes: 66c915d09b94 ("mmc: core: Disable card detect during shutdown")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Closes: https://lore.kernel.org/all/BN0PR08MB695133000AF116F04C3A9FFE83212@BN0PR08MB6951.namprd08.prod.outlook.com/
    Tested-by: Anthony Pighin <anthony.pighin@nokia.com>
    Message-ID: <20241125122446.18684-1-ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 374914d90a7cf6b38f6a787a878fb523debeb685
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Nov 18 22:00:49 2024 +0100

    mmc: sdhci-pci: Add DMI quirk for missing CD GPIO on Vexia Edu Atla 10 tablet
    
    commit 7f0fa47ceebcff0e3591bb7e32a71a2cd7846149 upstream.
    
    The Vexia Edu Atla 10 tablet distributed to schools in the Spanish
    Andalucía region has no ACPI fwnode associated with the SDHCI controller
    for its microsd-slot and thus has no ACPI GPIO resource info.
    
    This causes the following error to be logged and the slot to not work:
    [   10.572113] sdhci-pci 0000:00:12.0: failed to setup card detect gpio
    
    Add a DMI quirk table for providing gpiod_lookup_tables with manually
    provided CD GPIO info and use this DMI table to provide the CD GPIO info
    on this tablet. This fixes the microsd-slot not working.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Message-ID: <20241118210049.311079-1-hdegoede@redhat.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48dc44f3c1afa29390cb2fbc8badad1b1111cea4
Author: Cosmin Tanislav <demonsingur@gmail.com>
Date:   Thu Nov 28 15:16:23 2024 +0200

    regmap: detach regmap from dev on regmap_exit
    
    commit 3061e170381af96d1e66799d34264e6414d428a7 upstream.
    
    At the end of __regmap_init(), if dev is not NULL, regmap_attach_dev()
    is called, which adds a devres reference to the regmap, to be able to
    retrieve a dev's regmap by name using dev_get_regmap().
    
    When calling regmap_exit, the opposite does not happen, and the
    reference is kept until the dev is detached.
    
    Add a regmap_detach_dev() function and call it in regmap_exit() to make
    sure that the devres reference is not kept.
    
    Cc: stable@vger.kernel.org
    Fixes: 72b39f6f2b5a ("regmap: Implement dev_get_regmap()")
    Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
    Rule: add
    Link: https://lore.kernel.org/stable/20241128130554.362486-1-demonsingur%40gmail.com
    Link: https://patch.msgid.link/20241128131625.363835-1-demonsingur@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed08c93d5a9801cc8f224a046411fd603c538d07
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Fri Nov 22 13:10:29 2024 +0100

    xsk: fix OOB map writes when deleting elements
    
    commit 32cd3db7de97c0c7a018756ce66244342fd583f0 upstream.
    
    Jordy says:
    
    "
    In the xsk_map_delete_elem function an unsigned integer
    (map->max_entries) is compared with a user-controlled signed integer
    (k). Due to implicit type conversion, a large unsigned value for
    map->max_entries can bypass the intended bounds check:
    
            if (k >= map->max_entries)
                    return -EINVAL;
    
    This allows k to hold a negative value (between -2147483648 and -2),
    which is then used as an array index in m->xsk_map[k], which results
    in an out-of-bounds access.
    
            spin_lock_bh(&m->lock);
            map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
            old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
            if (old_xs)
                    xsk_map_sock_delete(old_xs, map_entry);
            spin_unlock_bh(&m->lock);
    
    The xchg operation can then be used to cause an out-of-bounds write.
    Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead
    to further memory corruption.
    "
    
    It indeed results in following splat:
    
    [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108
    [76612.904330] #PF: supervisor write access in kernel mode
    [76612.909639] #PF: error_code(0x0002) - not-present page
    [76612.914855] PGD 0 P4D 0
    [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP
    [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470
    [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
    [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60
    [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31
    [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246
    [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000
    [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000
    [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007
    [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8
    [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0
    [76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000
    [76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0
    [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [76613.041086] PKRU: 55555554
    [76613.043842] Call Trace:
    [76613.046331]  <TASK>
    [76613.048468]  ? __die+0x20/0x60
    [76613.051581]  ? page_fault_oops+0x15a/0x450
    [76613.055747]  ? search_extable+0x22/0x30
    [76613.059649]  ? search_bpf_extables+0x5f/0x80
    [76613.063988]  ? exc_page_fault+0xa9/0x140
    [76613.067975]  ? asm_exc_page_fault+0x22/0x30
    [76613.072229]  ? xsk_map_delete_elem+0x2d/0x60
    [76613.076573]  ? xsk_map_delete_elem+0x23/0x60
    [76613.080914]  __sys_bpf+0x19b7/0x23c0
    [76613.084555]  __x64_sys_bpf+0x1a/0x20
    [76613.088194]  do_syscall_64+0x37/0xb0
    [76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
    [76613.096962] RIP: 0033:0x7f80b6d1e88d
    [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48
    [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141
    [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d
    [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003
    [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000
    [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8
    [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00007f80b6fab040
    [76613.188129]  </TASK>
    
    Fix this by simply changing key type from int to u32.
    
    Fixes: fbfc504a24f5 ("bpf: introduce new bpf AF_XDP map type BPF_MAP_TYPE_XSKMAP")
    CC: stable@vger.kernel.org
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Suggested-by: Jordy Zomer <jordyzomer@google.com>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/r/20241122121030.716788-2-maciej.fijalkowski@intel.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0af08132eec552b1811a89bce7f4834b65f9ead3
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Date:   Fri Nov 15 10:21:50 2024 +0000

    dma-fence: Use kernel's sort for merging fences
    
    commit fe52c649438b8489c9456681d93a9b3de3d38263 upstream.
    
    One alternative to the fix Christian proposed in
    https://lore.kernel.org/dri-devel/20241024124159.4519-3-christian.koenig@amd.com/
    is to replace the rather complex open coded sorting loops with the kernel
    standard sort followed by a context squashing pass.
    
    Proposed advantage of this would be readability but one concern Christian
    raised was that there could be many fences, that they are typically mostly
    sorted, and so the kernel's heap sort would be much worse by the proposed
    algorithm.
    
    I had a look running some games and vkcube to see what are the typical
    number of input fences. Tested scenarios:
    
    1) Hogwarts Legacy under Gamescope
    
    450 calls per second to __dma_fence_unwrap_merge.
    
    Percentages per number of fences buckets, before and after checking for
    signalled status, sorting and flattening:
    
       N       Before      After
       0       0.91%
       1      69.40%
      2-3     28.72%       9.4%  (90.6% resolved to one fence)
      4-5      0.93%
      6-9      0.03%
      10+
    
    2) Cyberpunk 2077 under Gamescope
    
    1050 calls per second, amounting to 0.01% CPU time according to perf top.
    
       N       Before      After
       0       1.13%
       1      52.30%
      2-3     40.34%       55.57%
      4-5      1.46%        0.50%
      6-9      2.44%
      10+      2.34%
    
    3) vkcube under Plasma
    
    90 calls per second.
    
       N       Before      After
       0
       1
      2-3      100%         0%   (Ie. all resolved to a single fence)
      4-5
      6-9
      10+
    
    In the case of vkcube all invocations in the 2-3 bucket were actually
    just two input fences.
    
    From these numbers it looks like the heap sort should not be a
    disadvantage, given how the dominant case is <= 2 input fences which heap
    sort solves with just one compare and swap. (And for the case of one input
    fence we have a fast path in the previous patch.)
    
    A complementary possibility is to implement a different sorting algorithm
    under the same API as the kernel's sort() and so keep the simplicity,
    potentially moving the new sort under lib/ if it would be found more
    widely useful.
    
    v2:
     * Hold on to fence references and reduce commentary. (Christian)
     * Record and use latest signaled timestamp in the 2nd loop too.
     * Consolidate zero or one fences fast paths.
    
    v3:
     * Reverse the seqno sort order for a simpler squashing pass. (Christian)
    
    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Fixes: 245a4a7b531c ("dma-buf: generalize dma_fence unwrap & merging v3")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3617
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Sumit Semwal <sumit.semwal@linaro.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Friedrich Vock <friedrich.vock@gmx.de>
    Cc: linux-media@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: linaro-mm-sig@lists.linaro.org
    Cc: <stable@vger.kernel.org> # v6.0+
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241115102153.1980-3-tursulin@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 033e49e92fd51f1efed92aea1f35f71b13ad41ac
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Date:   Fri Nov 15 10:21:49 2024 +0000

    dma-fence: Fix reference leak on fence merge failure path
    
    commit 949291c5314009b4f6e252391edbb40fdd5d5414 upstream.
    
    Release all fence references if the output dma-fence-array could not be
    allocated.
    
    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Fixes: 245a4a7b531c ("dma-buf: generalize dma_fence unwrap & merging v3")
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Sumit Semwal <sumit.semwal@linaro.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Friedrich Vock <friedrich.vock@gmx.de>
    Cc: linux-media@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: linaro-mm-sig@lists.linaro.org
    Cc: <stable@vger.kernel.org> # v6.0+
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241115102153.1980-2-tursulin@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dee6bfab0e7c94cee9fd511b2301174305cb315
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Nov 8 09:29:48 2024 +0100

    dma-buf: fix dma_fence_array_signaled v4
    
    commit 78ac1c3558810486d90aa533b0039aa70487a3da upstream.
    
    The function silently assumed that signaling was already enabled for the
    dma_fence_array. This meant that without enabling signaling first we would
    never see forward progress.
    
    Fix that by falling back to testing each individual fence when signaling
    isn't enabled yet.
    
    v2: add the comment suggested by Boris why this is done this way
    v3: fix the underflow pointed out by Tvrtko
    v4: atomic_read_acquire() as suggested by Tvrtko
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
    Tested-by: Chia-I Wu <olvaffe@gmail.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
    Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12094
    Cc: <stable@vger.kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241112121925.18464-1-christian.koenig@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98c03d05936d846073df8f550e9e8bf0dde1d77f
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Fri Nov 22 13:10:30 2024 +0100

    bpf: fix OOB devmap writes when deleting elements
    
    commit ab244dd7cf4c291f82faacdc50b45cc0f55b674d upstream.
    
    Jordy reported issue against XSKMAP which also applies to DEVMAP - the
    index used for accessing map entry, due to being a signed integer,
    causes the OOB writes. Fix is simple as changing the type from int to
    u32, however, when compared to XSKMAP case, one more thing needs to be
    addressed.
    
    When map is released from system via dev_map_free(), we iterate through
    all of the entries and an iterator variable is also an int, which
    implies OOB accesses. Again, change it to be u32.
    
    Example splat below:
    
    [  160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000
    [  160.731662] #PF: supervisor read access in kernel mode
    [  160.736876] #PF: error_code(0x0000) - not-present page
    [  160.742095] PGD 0 P4D 0
    [  160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP
    [  160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487
    [  160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
    [  160.767642] Workqueue: events_unbound bpf_map_free_deferred
    [  160.773308] RIP: 0010:dev_map_free+0x77/0x170
    [  160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff
    [  160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202
    [  160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024
    [  160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000
    [  160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001
    [  160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122
    [  160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000
    [  160.838310] FS:  0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000
    [  160.846528] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0
    [  160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  160.874092] PKRU: 55555554
    [  160.876847] Call Trace:
    [  160.879338]  <TASK>
    [  160.881477]  ? __die+0x20/0x60
    [  160.884586]  ? page_fault_oops+0x15a/0x450
    [  160.888746]  ? search_extable+0x22/0x30
    [  160.892647]  ? search_bpf_extables+0x5f/0x80
    [  160.896988]  ? exc_page_fault+0xa9/0x140
    [  160.900973]  ? asm_exc_page_fault+0x22/0x30
    [  160.905232]  ? dev_map_free+0x77/0x170
    [  160.909043]  ? dev_map_free+0x58/0x170
    [  160.912857]  bpf_map_free_deferred+0x51/0x90
    [  160.917196]  process_one_work+0x142/0x370
    [  160.921272]  worker_thread+0x29e/0x3b0
    [  160.925082]  ? rescuer_thread+0x4b0/0x4b0
    [  160.929157]  kthread+0xd4/0x110
    [  160.932355]  ? kthread_park+0x80/0x80
    [  160.936079]  ret_from_fork+0x2d/0x50
    [  160.943396]  ? kthread_park+0x80/0x80
    [  160.950803]  ret_from_fork_asm+0x11/0x20
    [  160.958482]  </TASK>
    
    Fixes: 546ac1ffb70d ("bpf: add devmap, a map for storing net device references")
    CC: stable@vger.kernel.org
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Suggested-by: Jordy Zomer <jordyzomer@google.com>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/r/20241122121030.716788-3-maciej.fijalkowski@intel.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c23abcb314dced77869e6c8da4896da3280a86f1
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Dec 1 12:17:30 2024 +0100

    modpost: Add .irqentry.text to OTHER_SECTIONS
    
    commit 7912405643a14b527cd4a4f33c1d4392da900888 upstream.
    
    The compiler can fully inline the actual handler function of an interrupt
    entry into the .irqentry.text entry point. If such a function contains an
    access which has an exception table entry, modpost complains about a
    section mismatch:
    
      WARNING: vmlinux.o(__ex_table+0x447c): Section mismatch in reference ...
    
      The relocation at __ex_table+0x447c references section ".irqentry.text"
      which is not in the list of authorized sections.
    
    Add .irqentry.text to OTHER_SECTIONS to cure the issue.
    
    Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org # needed for linux-5.4-y
    Link: https://lore.kernel.org/all/20241128111844.GE10431@google.com/
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [ bump the size of good_tosec[] to prevent overflow - gregkh ]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0cbcf1f77dc4b78740ee2478fd32097acb06cea
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Nov 22 11:24:13 2024 -0500

    drm/amdgpu/hdp5.2: do a posting read when flushing HDP
    
    commit f756dbac1ce1d5f9a2b35e3b55fa429cf6336437 upstream.
    
    Need to read back to make sure the write goes through.
    
    Cc: David Belanger <david.belanger@amd.com>
    Reviewed-by: Frank Min <frank.min@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>

commit 94b33b2d7640e807869451384eb88321dd0ffbd4
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Dec 3 18:02:17 2024 +0200

    drm/dp_mst: Fix resetting msg rx state after topology removal
    
    commit a6fa67d26de385c3c7a23c1e109a0e23bfda4ec7 upstream.
    
    If the MST topology is removed during the reception of an MST down reply
    or MST up request sideband message, the
    drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset
    from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with
    the reading/parsing of the message from another thread via
    drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is
    possible since the reader/parser doesn't hold any lock while accessing
    the reception state. This in turn can lead to a memory corruption in the
    reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST
    sideband message body length check").
    
    Fix the above by resetting the message reception state if needed before
    reading/parsing a message. Another solution would be to hold the
    drm_dp_mst_topology_mgr::lock for the whole duration of the message
    reception/parsing in drm_dp_mst_handle_down_rep() and
    drm_dp_mst_handle_up_req(), however this would require a bigger change.
    Since the fix is also needed for stable, opting for the simpler solution
    in this patch.
    
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 1d082618bbf3 ("drm/display/dp_mst: Fix down/up message handling after sink disconnect")
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13056
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241203160223.2926014-2-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0afd7eadca3d9c3284f03fda530e86bbb45c1b3
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Dec 3 18:02:18 2024 +0200

    drm/dp_mst: Verify request type in the corresponding down message reply
    
    commit 4d49e77a973d3b5d1881663c3f122906a0702940 upstream.
    
    After receiving the response for an MST down request message, the
    response should be accepted/parsed only if the response type matches
    that of the request. Ensure this by checking if the request type code
    stored both in the request and the reply match, dropping the reply in
    case of a mismatch.
    
    This fixes the topology detection for an MST hub, as described in the
    Closes link below, where the hub sends an incorrect reply message after
    a CLEAR_PAYLOAD_TABLE -> LINK_ADDRESS down request message sequence.
    
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: <stable@vger.kernel.org>
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12804
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241203160223.2926014-3-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 780fa184d4dc38ad6c4fded345ab8f9be7a63e96
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Nov 25 22:53:14 2024 +0200

    drm/dp_mst: Fix MST sideband message body length check
    
    commit bd2fccac61b40eaf08d9546acc9fef958bfe4763 upstream.
    
    Fix the MST sideband message body length check, which must be at least 1
    byte accounting for the message body CRC (aka message data CRC) at the
    end of the message.
    
    This fixes a case where an MST branch device returns a header with a
    correct header CRC (indicating a correctly received body length), with
    the body length being incorrectly set to 0. This will later lead to a
    memory corruption in drm_dp_sideband_append_payload() and the following
    errors in dmesg:
    
       UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25
       index -1 is out of range for type 'u8 [48]'
       Call Trace:
        drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]
        drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]
        drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
    
       memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)
       Call Trace:
        drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]
        drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]
        drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
    
    Cc: <stable@vger.kernel.org>
    Cc: Lyude Paul <lyude@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241125205314.1725887-1-imre.deak@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5202391970ffbf81975251b3526b890ba027b715
Author: Liequan Che <cheliequan@inspur.com>
Date:   Mon Dec 2 19:56:38 2024 +0800

    bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again
    
    commit b2e382ae12a63560fca35050498e19e760adf8c0 upstream.
    
    Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in
    node allocations") leads a NULL pointer deference in cache_set_flush().
    
    1721         if (!IS_ERR_OR_NULL(c->root))
    1722                 list_add(&c->root->list, &c->btree_cache);
    
    >From the above code in cache_set_flush(), if previous registration code
    fails before allocating c->root, it is possible c->root is NULL as what
    it is initialized. __bch_btree_node_alloc() never returns NULL but
    c->root is possible to be NULL at above line 1721.
    
    This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
    
    Fixes: 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations")
    Signed-off-by: Liequan Che <cheliequan@inspur.com>
    Cc: stable@vger.kernel.org
    Cc: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20241202115638.28957-1-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5af8366625182f01f6d8465c9a3210574673af57
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Nov 20 02:23:37 2024 +0900

    nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()
    
    commit 985ebec4ab0a28bb5910c3b1481a40fbf7f9e61d upstream.
    
    Syzbot reported that when searching for records in a directory where the
    inode's i_size is corrupted and has a large value, memory access outside
    the folio/page range may occur, or a use-after-free bug may be detected if
    KASAN is enabled.
    
    This is because nilfs_last_byte(), which is called by nilfs_find_entry()
    and others to calculate the number of valid bytes of directory data in a
    page from i_size and the page index, loses the upper 32 bits of the 64-bit
    size information due to an inappropriate type of local variable to which
    the i_size value is assigned.
    
    This caused a large byte offset value due to underflow in the end address
    calculation in the calling nilfs_find_entry(), resulting in memory access
    that exceeds the folio/page size.
    
    Fix this issue by changing the type of the local variable causing the bit
    loss from "unsigned int" to "u64".  The return value of nilfs_last_byte()
    is also of type "unsigned int", but it is truncated so as not to exceed
    PAGE_SIZE and no bit loss occurs, so no change is required.
    
    Link: https://lkml.kernel.org/r/20241119172403.9292-1-konishi.ryusuke@gmail.com
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+96d5d14c47d97015c624@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=96d5d14c47d97015c624
    Tested-by: syzbot+96d5d14c47d97015c624@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 897222612979fa473a9b98f8f1907cfe09896cd6
Author: Peter Wang <peter.wang@mediatek.com>
Date:   Fri Nov 22 10:49:43 2024 +0800

    scsi: ufs: core: Add missing post notify for power mode change
    
    commit 7f45ed5f0cd5ccbbec79adc6c48a67d6a85fba56 upstream.
    
    When the power mode change is successful but the power mode hasn't
    actually changed, the post notification was missed.  Similar to the
    approach with hibernate/clock scale/hce enable, having pre/post
    notifications in the same function will make it easier to maintain.
    
    Additionally, supplement the description of power parameters for the
    pwr_change_notify callback.
    
    Fixes: 7eb584db73be ("ufs: refactor configuring power mode")
    Cc: stable@vger.kernel.org #6.11.x
    Signed-off-by: Peter Wang <peter.wang@mediatek.com>
    Link: https://lore.kernel.org/r/20241122024943.30589-1-peter.wang@mediatek.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>

commit 7b21233e5f72d10f08310689f993c1dbdfde9f2c
Author: Gwendal Grignou <gwendal@chromium.org>
Date:   Tue Nov 19 22:25:22 2024 -0800

    scsi: ufs: core: sysfs: Prevent div by zero
    
    commit eb48e9fc0028bed94a40a9352d065909f19e333c upstream.
    
    Prevent a division by 0 when monitoring is not enabled.
    
    Fixes: 1d8613a23f3c ("scsi: ufs: core: Introduce HBA performance monitor sysfs nodes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
    Link: https://lore.kernel.org/r/20241120062522.917157-1-gwendal@chromium.org
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7a2f0ce45bf8c9eae85ba0f1ee342d10779c3b5
Author: Saurav Kashyap <skashyap@marvell.com>
Date:   Fri Nov 15 18:33:10 2024 +0530

    scsi: qla2xxx: Remove check req_sg_cnt should be equal to rsp_sg_cnt
    
    commit 833c70e212fc40d3e98da941796f4c7bcaecdf58 upstream.
    
    Firmware supports multiple sg_cnt for request and response for CT
    commands, so remove the redundant check. A check is there where sg_cnt
    for request and response should be same. This is not required as driver
    and FW have code to handle multiple and different sg_cnt on request and
    response.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20241115130313.46826-5-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3e6f25176f248762a24d25ab8cf8c5e90874f80
Author: Quinn Tran <qutran@marvell.com>
Date:   Fri Nov 15 18:33:08 2024 +0530

    scsi: qla2xxx: Fix use after free on unload
    
    commit 07c903db0a2ff84b68efa1a74a4de353ea591eb0 upstream.
    
    System crash is observed with stack trace warning of use after
    free. There are 2 signals to tell dpc_thread to terminate (UNLOADING
    flag and kthread_stop).
    
    On setting the UNLOADING flag when dpc_thread happens to run at the time
    and sees the flag, this causes dpc_thread to exit and clean up
    itself. When kthread_stop is called for final cleanup, this causes use
    after free.
    
    Remove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop
    as the main signal to exit dpc_thread.
    
    [596663.812935] kernel BUG at mm/slub.c:294!
    [596663.812950] invalid opcode: 0000 [#1] SMP PTI
    [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1
    [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012
    [596663.812974] RIP: 0010:__slab_free+0x17d/0x360
    
    ...
    [596663.813008] Call Trace:
    [596663.813022]  ? __dentry_kill+0x121/0x170
    [596663.813030]  ? _cond_resched+0x15/0x30
    [596663.813034]  ? _cond_resched+0x15/0x30
    [596663.813039]  ? wait_for_completion+0x35/0x190
    [596663.813048]  ? try_to_wake_up+0x63/0x540
    [596663.813055]  free_task+0x5a/0x60
    [596663.813061]  kthread_stop+0xf3/0x100
    [596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx]
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20241115130313.46826-3-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f3e10e9c20df4968a883b088775e7af149ec818
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Fri Nov 15 18:33:12 2024 +0530

    scsi: qla2xxx: Supported speed displayed incorrectly for VPorts
    
    commit e4e268f898c8a08f0a1188677e15eadbc06e98f6 upstream.
    
    The fc_function_template for vports was missing the
    .show_host_supported_speeds. The base port had the same.
    
    Add .show_host_supported_speeds to the vport template as well.
    
    Cc: stable@vger.kernel.org
    Fixes: 2c3dfe3f6ad8 ("[SCSI] qla2xxx: add support for NPIV")
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20241115130313.46826-7-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61cee384593c60818ba085ba41b823053164c2ec
Author: Quinn Tran <qutran@marvell.com>
Date:   Fri Nov 15 18:33:11 2024 +0530

    scsi: qla2xxx: Fix NVMe and NPIV connect issue
    
    commit 4812b7796c144f63a1094f79a5eb8fbdad8d7ebc upstream.
    
    NVMe controller fails to send connect command due to failure to locate
    hw context buffer for NVMe queue 0 (blk_mq_hw_ctx, hctx_idx=0). The
    cause of the issue is NPIV host did not initialize the vha->irq_offset
    field.  This field is given to blk-mq (blk_mq_pci_map_queues) to help
    locate the beginning of IO Queues which in turn help locate NVMe queue
    0.
    
    Initialize this field to allow NVMe to work properly with NPIV host.
    
     kernel: nvme nvme5: Connect command failed, errno: -18
     kernel: nvme nvme5: qid 0: secure concatenation is not supported
     kernel: nvme nvme5: NVME-FC{5}: create_assoc failed, assoc_id 2e9100 ret 401
     kernel: nvme nvme5: NVME-FC{5}: reset: Reconnect attempt failed (401)
     kernel: nvme nvme5: NVME-FC{5}: Reconnect attempt in 2 seconds
    
    Cc: stable@vger.kernel.org
    Fixes: f0783d43dde4 ("scsi: qla2xxx: Use correct number of vectors for online CPUs")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20241115130313.46826-6-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b8b9c0eeeb679e5e1978a9b98a8c52f3171e037
Author: Quinn Tran <qutran@marvell.com>
Date:   Fri Nov 15 18:33:07 2024 +0530

    scsi: qla2xxx: Fix abort in bsg timeout
    
    commit c423263082ee8ccfad59ab33e3d5da5dc004c21e upstream.
    
    Current abort of bsg on timeout prematurely clears the
    outstanding_cmds[]. Abort does not allow FW to return the IOCB/SRB. In
    addition, bsg_job_done() is not called to return the BSG (i.e. leak).
    
    Abort the outstanding bsg/SRB and wait for the completion. The
    completion IOCB will wake up the bsg_timeout thread. If abort is not
    successful, then driver will forcibly call bsg_job_done() and free the
    srb.
    
    Err Inject:
    
     - qaucli -z
     - assign CT Passthru IOCB's NportHandle with another initiator
       nport handle to trigger timeout.  Remote port will drop CT request.
     - bsg_job_done is properly called as part of cleanup
    
    kernel: qla2xxx [0000:21:00.1]-7012:7: qla2x00_process_ct : 286 : Error Inject.
    kernel: qla2xxx [0000:21:00.1]-7016:7: bsg rqst type: FC_BSG_HST_CT else type: 101 - loop-id=1 portid=fffffa.
    kernel: qla2xxx [0000:21:00.1]-70bb:7: qla24xx_bsg_timeout CMD timeout. bsg ptr ffff9971a42f0838 msgcode 80000004 vendor cmd fa010000
    kernel: qla2xxx [0000:21:00.1]-507c:7: Abort command issued - hdl=4b, type=5
    kernel: qla2xxx [0000:21:00.1]-5040:7: ELS-CT pass-through-ct pass-through error hdl=4b comp_status-status=0x5 error subcode 1=0x0 error subcode 2=0xaf882e80.
    kernel: qla2xxx [0000:21:00.1]-7009:7: qla2x00_bsg_job_done: sp hdl 4b, result=70000 bsg ptr ffff9971a42f0838
    kernel: qla2xxx [0000:21:00.1]-802c:7: Aborting bsg ffff9971a42f0838 sp=ffff99760b87ba80 handle=4b rval=0
    kernel: qla2xxx [0000:21:00.1]-708a:7: bsg abort success. bsg ffff9971a42f0838 sp=ffff99760b87ba80 handle=0x4b
    kernel: qla2xxx [0000:21:00.1]-7012:7: qla2x00_process_ct : 286 : Error Inject.
    kernel: qla2xxx [0000:21:00.1]-7016:7: bsg rqst type: FC_BSG_HST_CT else type: 101 - loop-id=1 portid=fffffa.
    kernel: qla2xxx [0000:21:00.1]-70bb:7: qla24xx_bsg_timeout CMD timeout. bsg ptr ffff9971a42f43b8 msgcode 80000004 vendor cmd fa010000
    kernel: qla2xxx [0000:21:00.1]-7012:7: qla_bsg_found : 2206 : Error Inject 2.
    kernel: qla2xxx [0000:21:00.1]-802c:7: Aborting bsg ffff9971a42f43b8 sp=ffff99762c304440 handle=5e rval=5
    kernel: qla2xxx [0000:21:00.1]-704f:7: bsg abort fail.  bsg=ffff9971a42f43b8 sp=ffff99762c304440 rval=5.
    kernel: qla2xxx [0000:21:00.1]-7051:7: qla_bsg_found bsg_job_done : bsg ffff9971a42f43b8 result 0xfffffffa sp ffff99762c304440.
    
    Cc: stable@vger.kernel.org
    Fixes: c449b4198701 ("scsi: qla2xxx: Use QP lock to search for bsg")
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20241115130313.46826-2-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed4e9fa189aea814d8ac737099aff239dd4aa659
Author: Sahas Leelodharry <sahas.leelodharry@mail.mcgill.ca>
Date:   Mon Dec 2 03:28:33 2024 +0000

    ALSA: hda/realtek: Add support for Samsung Galaxy Book3 360 (NP730QFG)
    
    commit e2974a220594c06f536e65dfd7b2447e0e83a1cb upstream.
    
    Fixes the 3.5mm headphone jack on the Samsung Galaxy Book 3 360
    NP730QFG laptop.
    Unlike the other Galaxy Book3 series devices, this device only needs
    the ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET quirk.
    Verified changes on the device and compared with codec state in Windows.
    
    [ white-space fixes by tiwai ]
    
    Signed-off-by: Sahas Leelodharry <sahas.leelodharry@mail.mcgill.ca>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/QB1PR01MB40047D4CC1282DB7F1333124CC352@QB1PR01MB4004.CANPRD01.PROD.OUTLOOK.COM
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 388ff61cf047dde17e964b504f1c340b88619f61
Author: Nazar Bilinskyi <nbilinskyi@gmail.com>
Date:   Sun Dec 1 01:16:31 2024 +0200

    ALSA: hda/realtek: Enable mute and micmute LED on HP ProBook 430 G8
    
    commit 3a83f7baf1346aca885cb83cb888e835fef7c472 upstream.
    
    HP ProBook 430 G8 has a mute and micmute LEDs that can be made to work
    using quirk ALC236_FIXUP_HP_GPIO_LED. Enable already existing quirk.
    
    Signed-off-by: Nazar Bilinskyi <nbilinskyi@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241130231631.8929-1-nbilinskyi@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e72135e075f9d40e94d24b97de363b64368ba4a
Author: Marie Ramlow <me@nycode.dev>
Date:   Sat Nov 30 17:52:40 2024 +0100

    ALSA: usb-audio: add mixer mapping for Corsair HS80
    
    commit a7de2b873f3dbcda02d504536f1ec6dc50e3f6c4 upstream.
    
    The Corsair HS80 RGB Wireless is a USB headset with a mic and a sidetone
    feature. It has the same quirk as the Virtuoso series.
    This labels the mixers appropriately, so applications don't
    move the sidetone volume when they actually intend to move the main
    headset volume.
    
    Signed-off-by: Marie Ramlow <me@nycode.dev>
    cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241130165240.17838-1-me@nycode.dev
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1370cf3eb5495d70e00547598583a4cd45b40b99
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Thu Dec 5 12:16:52 2024 +0000

    arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
    
    commit ca62d90085f4af36de745883faab9f8a7cbb45d3 upstream.
    
    Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'
    variable, and a SETREGSET call with a length of zero will leave this
    uninitialized. Consequently tagged_addr_ctrl_set() will consume an
    arbitrary value, potentially leaking up to 64 bits of memory from the
    kernel stack. The read is limited to a specific slot on the stack, and
    the issue does not provide a write mechanism.
    
    As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and
    rejects other values, a partial SETREGSET attempt will randomly succeed
    or fail depending on the value of the uninitialized value, and the
    exposure is significantly limited.
    
    Fix this by initializing the temporary value before copying the regset
    from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
    NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
    value of the tagged address ctrl will be retained.
    
    The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the
    user_aarch64_view used by a native AArch64 task to manipulate another
    native AArch64 task. As get_tagged_addr_ctrl() only returns an error
    value when called for a compat task, tagged_addr_ctrl_get() and
    tagged_addr_ctrl_set() should never observe an error value from
    get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that
    such an error would be unexpected, and error handlnig is not missing in
    either case.
    
    Fixes: 2200aa7154cb ("arm64: mte: ptrace: Add NT_ARM_TAGGED_ADDR_CTRL regset")
    Cc: <stable@vger.kernel.org> # 5.10.x
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20241205121655.1824269-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83df26299d7c27fe0c3a7ae703c6449bb7faee4f
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue Dec 3 15:19:41 2024 +0000

    arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs
    
    commit c0900d15d31c2597dd9f634c8be2b71762199890 upstream.
    
    Linux currently sets the TCR_EL1.AS bit unconditionally during CPU
    bring-up. On an 8-bit ASID CPU, this is RES0 and ignored, otherwise
    16-bit ASIDs are enabled. However, if running in a VM and the hypervisor
    reports 8-bit ASIDs (ID_AA64MMFR0_EL1.ASIDBits == 0) on a 16-bit ASIDs
    CPU, Linux uses bits 8 to 63 as a generation number for tracking old
    process ASIDs. The bottom 8 bits of this generation end up being written
    to TTBR1_EL1 and also used for the ASID-based TLBI operations as the
    upper 8 bits of the ASID. Following an ASID roll-over event we can have
    threads of the same application with the same 8-bit ASID but different
    generation numbers running on separate CPUs. Both TLB caching and the
    TLBI operations will end up using different actual 16-bit ASIDs for the
    same process.
    
    A similar scenario can happen in a big.LITTLE configuration if the boot
    CPU only uses 8-bit ASIDs while secondary CPUs have 16-bit ASIDs.
    
    Ensure that the ASID generation is only tracked by bits 16 and up,
    leaving bits 15:8 as 0 if the kernel uses 8-bit ASIDs. Note that
    clearing TCR_EL1.AS is not sufficient since the architecture requires
    that the top 8 bits of the ASID passed to TLBI instructions are 0 rather
    than ignored in such configuration.
    
    Cc: stable@vger.kernel.org
    Cc: Will Deacon <will@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20241203151941.353796-1-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 896c1557f820c65fff9269f9e828074c62cae6db
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Wed Dec 4 04:22:28 2024 +0800

    tracing: Fix cmp_entries_dup() to respect sort() comparison rules
    
    commit e63fbd5f6810ed756bbb8a1549c7d4132968baa9 upstream.
    
    The cmp_entries_dup() function used as the comparator for sort()
    violated the symmetry and transitivity properties required by the
    sorting algorithm. Specifically, it returned 1 whenever memcmp() was
    non-zero, which broke the following expectations:
    
    * Symmetry: If x < y, then y > x.
    * Transitivity: If x < y and y < z, then x < z.
    
    These violations could lead to incorrect sorting and failure to
    correctly identify duplicate elements.
    
    Fix the issue by directly returning the result of memcmp(), which
    adheres to the required comparison properties.
    
    Cc: stable@vger.kernel.org
    Fixes: 08d43a5fa063 ("tracing: Add lock-free tracing_map")
    Link: https://lore.kernel.org/20241203202228.1274403-1-visitorckw@gmail.com
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfd8d65d84e689914f7dbce83ae52cb60a23465a
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sun Nov 24 18:42:56 2024 +0100

    can: mcp251xfd: mcp251xfd_get_tef_len(): work around erratum DS80000789E 6.
    
    commit 30447a1bc0e066e492552b3e5ffeb63c1605dfe2 upstream.
    
    Commit b8e0ddd36ce9 ("can: mcp251xfd: tef: prepare to workaround
    broken TEF FIFO tail index erratum") introduced
    mcp251xfd_get_tef_len() to get the number of unhandled transmit events
    from the Transmit Event FIFO (TEF).
    
    As the TEF has no head index, the driver uses the TX-FIFO's tail index
    instead, assuming that send frames are completed.
    
    When calculating the number of unhandled TEF events, that commit
    didn't take mcp2518fd erratum DS80000789E 6. into account. According
    to that erratum, the FIFOCI bits of a FIFOSTA register, here the
    TX-FIFO tail index might be corrupted.
    
    However here it seems the bit indicating that the TX-FIFO is
    empty (MCP251XFD_REG_FIFOSTA_TFERFFIF) is not correct while the
    TX-FIFO tail index is.
    
    Assume that the TX-FIFO is indeed empty if:
    - Chip's head and tail index are equal (len == 0).
    - The TX-FIFO is less than half full.
      (The TX-FIFO empty case has already been checked at the
       beginning of this function.)
    - No free buffers in the TX ring.
    
    If the TX-FIFO is assumed to be empty, assume that the TEF is full and
    return the number of elements in the TX-FIFO (which equals the number
    of TEF elements).
    
    If these assumptions are false, the driver might read to many objects
    from the TEF. mcp251xfd_handle_tefif_one() checks the sequence numbers
    and will refuse to process old events.
    
    Reported-by: Renjaya Raga Zenta <renjaya.zenta@formulatrix.com>
    Closes: https://patch.msgid.link/CAJ7t6HgaeQ3a_OtfszezU=zB-FqiZXqrnATJ3UujNoQJJf7GgA@mail.gmail.com
    Fixes: b8e0ddd36ce9 ("can: mcp251xfd: tef: prepare to workaround broken TEF FIFO tail index erratum")
    Tested-by: Renjaya Raga Zenta <renjaya.zenta@formulatrix.com>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20241126-mcp251xfd-fix-length-calculation-v2-1-c2ed516ed6ba@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46637a608fb1ee871a0ad8bf70d917d5d95ac251
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Nov 21 11:08:25 2024 +0100

    can: dev: can_set_termination(): allow sleeping GPIOs
    
    commit ee1dfbdd8b4b6de85e96ae2059dc9c1bdb6b49b5 upstream.
    
    In commit 6e86a1543c37 ("can: dev: provide optional GPIO based
    termination support") GPIO based termination support was added.
    
    For no particular reason that patch uses gpiod_set_value() to set the
    GPIO. This leads to the following warning, if the systems uses a
    sleeping GPIO, i.e. behind an I2C port expander:
    
    | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c
    | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c
    
    Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the
    use of sleeping GPIOs.
    
    Cc: Nicolai Buchwitz <nb@tipi-net.de>
    Cc: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Cc: stable@vger.kernel.org
    Reported-by: Leonard Göhrs <l.goehrs@pengutronix.de>
    Tested-by: Leonard Göhrs <l.goehrs@pengutronix.de>
    Fixes: 6e86a1543c37 ("can: dev: provide optional GPIO based termination support")
    Link: https://patch.msgid.link/20241121-dev-fix-can_set_termination-v1-1-41fa6e29216d@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b2f2abd279f8ca512ce54b98f9ec260de248612
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Date:   Thu Nov 7 21:38:28 2024 +0100

    watchdog: rti: of: honor timeout-sec property
    
    commit 4962ee045d8f06638714d801ab0fb72f89c16690 upstream.
    
    Currently "timeout-sec" Device Tree property is being silently ignored:
    even though watchdog_init_timeout() is being used, the driver always passes
    "heartbeat" == DEFAULT_HEARTBEAT == 60 as argument.
    
    Fix this by setting struct watchdog_device::timeout to DEFAULT_HEARTBEAT
    and passing real module parameter value to watchdog_init_timeout() (which
    may now be 0 if not specified).
    
    Cc: stable@vger.kernel.org
    Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20241107203830.1068456-1-alexander.sverdlin@siemens.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8cd7490fc0f268883e86e840cda5311257af69ca
Author: Jordy Zomer <jordyzomer@google.com>
Date:   Thu Nov 28 09:33:25 2024 +0900

    ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
    
    commit 313dab082289e460391c82d855430ec8a28ddf81 upstream.
    
    An offset from client could be a negative value, It could allows
    to write data outside the bounds of the allocated buffer.
    Note that this issue is coming when setting
    'vfs objects = streams_xattr parameter' in ksmbd.conf.
    
    Cc: stable@vger.kernel.org # v5.15+
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Signed-off-by: Jordy Zomer <jordyzomer@google.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de4d790dcf53be41736239d7ee63849a16ff5d10
Author: Jordy Zomer <jordyzomer@google.com>
Date:   Thu Nov 28 09:32:45 2024 +0900

    ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
    
    commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 upstream.
    
    An offset from client could be a negative value, It could lead
    to an out-of-bounds read from the stream_buf.
    Note that this issue is coming when setting
    'vfs objects = streams_xattr parameter' in ksmbd.conf.
    
    Cc: stable@vger.kernel.org # v5.15+
    Reported-by: Jordy Zomer <jordyzomer@google.com>
    Signed-off-by: Jordy Zomer <jordyzomer@google.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dba3c45e333a3a2a01395b5f5e5f88f8baba74e4
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Mon Dec 2 16:42:08 2024 +0800

    LoongArch: Add architecture specific huge_pte_clear()
    
    commit 7cd1f5f77925ae905a57296932f0f9ef0dc364f8 upstream.
    
    When executing mm selftests run_vmtests.sh, there is such an error:
    
     BUG: Bad page state in process uffd-unit-tests  pfn:00000
     page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0
     flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)
     raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000
     raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
     page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
     Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat
        virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse
        nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs
     CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184
     Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
     Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000
             900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8
             900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001
             0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000
             0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000
             000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940
             0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000
             0000000000000000 90000000028f8940 ffff800000000000 0000000000000000
             0000000000000000 0000000000000000 9000000000223a94 000000012001839c
             00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d
             ...
     Call Trace:
     [<9000000000223a94>] show_stack+0x5c/0x180
     [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0
     [<900000000056aa08>] bad_page+0x1a0/0x1f0
     [<9000000000574978>] free_unref_folios+0xbf0/0xd20
     [<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8
     [<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260
     [<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0
     [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218
     [<9000000000543cb8>] exit_mmap+0x1a0/0x360
     [<9000000000247658>] __mmput+0x78/0x200
     [<900000000025583c>] do_exit+0x43c/0xde8
     [<9000000000256490>] do_group_exit+0x68/0x110
     [<9000000000256554>] sys_exit_group+0x1c/0x20
     [<9000000001c413b4>] do_syscall+0x94/0x130
     [<90000000002216d8>] handle_syscall+0xb8/0x158
     Disabling lock debugging due to kernel taint
     BUG: non-zero pgtables_bytes on freeing mm: -16384
    
    On LoongArch system, invalid huge pte entry should be invalid_pte_table
    or a single _PAGE_HUGE bit rather than a zero value. And it should be
    the same with invalid pmd entry, since pmd_none() is called by function
    free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single
    _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()
    will be called in free_pmd_range().
    
      free_pmd_range()
            pmd = pmd_offset(pud, addr);
            do {
                    next = pmd_addr_end(addr, end);
                    if (pmd_none_or_clear_bad(pmd))
                            continue;
                    free_pte_range(tlb, pmd, addr);
            } while (pmd++, addr = next, addr != end);
    
    Here invalid_pte_table is used for both invalid huge pte entry and
    pmd entry.
    
    Cc: stable@vger.kernel.org
    Fixes: 09cfefb7fa70 ("LoongArch: Add memory management")
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cd323c55bd3f356bf23ae1b4c20100abcdc29d6
Author: WangYuli <wangyuli@uniontech.com>
Date:   Mon Nov 25 13:26:16 2024 +0800

    HID: wacom: fix when get product name maybe null pointer
    
    commit 59548215b76be98cf3422eea9a67d6ea578aca3d upstream.
    
    Due to incorrect dev->product reporting by certain devices, null
    pointer dereferences occur when dev->product is empty, leading to
    potential system crashes.
    
    This issue was found on EXCELSIOR DL37-D05 device with
    Loongson-LS3A6000-7A2000-DL37 motherboard.
    
    Kernel logs:
    [   56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci
    [   56.671638] usb 4-3: string descriptor 0 read error: -22
    [   56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07
    [   56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [   56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0
    [   56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80
    [   56.697732] Oops[#1]:
    [   56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G           OE      6.6.0-loong64-desktop #25.00.2000.015
    [   56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024
    [   56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0
    [   56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000
    [   56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000
    [   56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005
    [   56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000
    [   56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028
    [   56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000
    [   56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000
    [   56.697753]    ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]
    [   56.697802]   ERA: 90000000066e35c8 strstr+0x28/0x120
    [   56.697806]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
    [   56.697816]  PRMD: 0000000c (PPLV0 +PIE +PWE)
    [   56.697821]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
    [   56.697827]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
    [   56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
    [   56.697835]  BADV: 0000000000000000
    [   56.697836]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)
    [   56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit
    [   56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)
    [   56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000
    [   56.697896]         0000000000000000 00000011fffffffd 0000000000000000 0000000000000000
    [   56.697901]         0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0
    [   56.697906]         90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c
    [   56.697911]         90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440
    [   56.697916]         ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0
    [   56.697921]         0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c
    [   56.697926]         ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000
    [   56.697931]         90000001000bb8d0 9000000006307564 9000000005e666e0 90000001752359b8
    [   56.697936]         9000000008cbe400 900000000804d000 9000000005e666e0 0000000000000000
    [   56.697941]         ...
    [   56.697944] Call Trace:
    [   56.697945] [<90000000066e35c8>] strstr+0x28/0x120
    [   56.697950] [<ffff800004f98a80>] wacom_update_name+0xe0/0x300 [wacom]
    [   56.698000] [<ffff800004f9ce58>] wacom_parse_and_register+0x338/0x900 [wacom]
    [   56.698050] [<ffff800004f9d74c>] wacom_probe+0x32c/0x420 [wacom]
    [   56.698099] [<9000000006307564>] hid_device_probe+0x144/0x260
    [   56.698103] [<9000000005e65d68>] really_probe+0x208/0x540
    [   56.698109] [<9000000005e661dc>] __driver_probe_device+0x13c/0x1e0
    [   56.698112] [<9000000005e66620>] driver_probe_device+0x40/0x100
    [   56.698116] [<9000000005e6680c>] __device_attach_driver+0x12c/0x180
    [   56.698119] [<9000000005e62bc8>] bus_for_each_drv+0x88/0x160
    [   56.698123] [<9000000005e66468>] __device_attach+0x108/0x260
    [   56.698126] [<9000000005e63918>] device_reprobe+0x78/0x100
    [   56.698129] [<9000000005e62a68>] bus_for_each_dev+0x88/0x160
    [   56.698132] [<9000000006304e54>] __hid_bus_driver_added+0x34/0x80
    [   56.698134] [<9000000005e62bc8>] bus_for_each_drv+0x88/0x160
    [   56.698137] [<9000000006304df0>] __hid_register_driver+0x70/0xa0
    [   56.698142] [<9000000004e10fe4>] do_one_initcall+0x104/0x320
    [   56.698146] [<9000000004f38150>] do_init_module+0x90/0x2c0
    [   56.698151] [<9000000004f3a3d8>] init_module_from_file+0xb8/0x120
    [   56.698155] [<9000000004f3a590>] idempotent_init_module+0x150/0x3a0
    [   56.698159] [<9000000004f3a890>] sys_finit_module+0xb0/0x140
    [   56.698163] [<900000000671e4e8>] do_syscall+0x88/0xc0
    [   56.698166] [<9000000004e12404>] handle_syscall+0xc4/0x160
    [   56.698171] Code: 0011958f  00150224  5800cd85 <2a00022c> 00150004  4000c180  0015022c  03400000  03400000
    [   56.698192] ---[ end trace 0000000000000000 ]---
    
    Fixes: 09dc28acaec7 ("HID: wacom: Improve generic name generation")
    Reported-by: Zhenxing Chen <chenzhenxing@uniontech.com>
    Co-developed-by: Xu Rao <raoxu@uniontech.com>
    Signed-off-by: Xu Rao <raoxu@uniontech.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Link: https://patch.msgid.link/B31757FE8E1544CF+20241125052616.18261-1-wangyuli@uniontech.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2521664c1fc0fcea825ef0b4d8e2dfb622bc0f9a
Author: Roman Gushchin <roman.gushchin@linux.dev>
Date:   Wed Nov 6 19:53:54 2024 +0000

    mm: page_alloc: move mlocked flag clearance into free_pages_prepare()
    
    commit 66edc3a5894c74f8887c8af23b97593a0dd0df4d upstream.
    
    Syzbot reported a bad page state problem caused by a page being freed
    using free_page() still having a mlocked flag at free_pages_prepare()
    stage:
    
      BUG: Bad page state in process syz.5.504  pfn:61f45
      page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45
      flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
      page_owner tracks the page as allocated
      page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394
       set_page_owner include/linux/page_owner.h:32 [inline]
       post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
       prep_new_page mm/page_alloc.c:1545 [inline]
       get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457
       __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733
       alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
       kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99
       kvm_create_vm virt/kvm/kvm_main.c:1235 [inline]
       kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline]
       kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530
       __do_compat_sys_ioctl fs/ioctl.c:1007 [inline]
       __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950
       do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
       __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
       do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
       entry_SYSENTER_compat_after_hwframe+0x84/0x8e
      page last free pid 8399 tgid 8399 stack trace:
       reset_page_owner include/linux/page_owner.h:25 [inline]
       free_pages_prepare mm/page_alloc.c:1108 [inline]
       free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686
       folios_put_refs+0x76c/0x860 mm/swap.c:1007
       free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335
       __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]
       tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]
       tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]
       tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373
       tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465
       exit_mmap+0x496/0xc40 mm/mmap.c:1926
       __mmput+0x115/0x390 kernel/fork.c:1348
       exit_mm+0x220/0x310 kernel/exit.c:571
       do_exit+0x9b2/0x28e0 kernel/exit.c:926
       do_group_exit+0x207/0x2c0 kernel/exit.c:1088
       __do_sys_exit_group kernel/exit.c:1099 [inline]
       __se_sys_exit_group kernel/exit.c:1097 [inline]
       __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
       x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
      Modules linked in:
      CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:94 [inline]
       dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
       bad_page+0x176/0x1d0 mm/page_alloc.c:501
       free_page_is_bad mm/page_alloc.c:918 [inline]
       free_pages_prepare mm/page_alloc.c:1100 [inline]
       free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638
       kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline]
       kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386
       kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143
       __fput+0x23f/0x880 fs/file_table.c:431
       task_work_run+0x24f/0x310 kernel/task_work.c:239
       exit_task_work include/linux/task_work.h:43 [inline]
       do_exit+0xa2f/0x28e0 kernel/exit.c:939
       do_group_exit+0x207/0x2c0 kernel/exit.c:1088
       __do_sys_exit_group kernel/exit.c:1099 [inline]
       __se_sys_exit_group kernel/exit.c:1097 [inline]
       __ia32_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
       ia32_sys_call+0x2624/0x2630 arch/x86/include/generated/asm/syscalls_32.h:253
       do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
       __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
       do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
       entry_SYSENTER_compat_after_hwframe+0x84/0x8e
      RIP: 0023:0xf745d579
      Code: Unable to access opcode bytes at 0xf745d54f.
      RSP: 002b:00000000f75afd6c EFLAGS: 00000206 ORIG_RAX: 00000000000000fc
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 00000000ffffff9c RDI: 00000000f744cff4
      RBP: 00000000f717ae61 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       </TASK>
    
    The problem was originally introduced by commit b109b87050df ("mm/munlock:
    replace clear_page_mlock() by final clearance"): it was focused on
    handling pagecache and anonymous memory and wasn't suitable for lower
    level get_page()/free_page() API's used for example by KVM, as with this
    reproducer.
    
    Fix it by moving the mlocked flag clearance down to free_page_prepare().
    
    The bug itself if fairly old and harmless (aside from generating these
    warnings), aside from a small memory leak - "bad" pages are stopped from
    being allocated again.
    
    Link: https://lkml.kernel.org/r/20241106195354.270757-1-roman.gushchin@linux.dev
    Fixes: b109b87050df ("mm/munlock: replace clear_page_mlock() by final clearance")
    Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
    Reported-by: syzbot+e985d3026c4fd041578e@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/6729f475.050a0220.701a.0019.GAE@google.com
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6b5e3c7cb2106583287ce98d76a0004b8900269
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Dec 6 19:06:18 2024 +0800

    bpf: Fix exact match conditions in trie_get_next_key()
    
    [ Upstream commit 27abc7b3fa2e09bbe41e2924d328121546865eda ]
    
    trie_get_next_key() uses node->prefixlen == key->prefixlen to identify
    an exact match, However, it is incorrect because when the target key
    doesn't fully match the found node (e.g., node->prefixlen != matchlen),
    these two nodes may also have the same prefixlen. It will return
    expected result when the passed key exist in the trie. However when a
    recently-deleted key or nonexistent key is passed to
    trie_get_next_key(), it may skip keys and return incorrect result.
    
    Fix it by using node->prefixlen == matchlen to identify exact matches.
    When the condition is true after the search, it also implies
    node->prefixlen equals key->prefixlen, otherwise, the search would
    return NULL instead.
    
    Fixes: b471f2f1de8b ("bpf: implement MAP_GET_NEXT_KEY command for LPM_TRIE map")
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20241206110622.1161752-6-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b332849f278741613ba7f36e038e66ed00921301
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Dec 6 19:06:17 2024 +0800

    bpf: Handle in-place update for full LPM trie correctly
    
    [ Upstream commit 532d6b36b2bfac5514426a97a4df8d103d700d43 ]
    
    When a LPM trie is full, in-place updates of existing elements
    incorrectly return -ENOSPC.
    
    Fix this by deferring the check of trie->n_entries. For new insertions,
    n_entries must not exceed max_entries. However, in-place updates are
    allowed even when the trie is full.
    
    Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation")
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20241206110622.1161752-5-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4fd0dde298a4f8d3f293f7b28d3519147bab01e
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Dec 6 19:06:15 2024 +0800

    bpf: Remove unnecessary kfree(im_node) in lpm_trie_update_elem
    
    [ Upstream commit 3d5611b4d7efbefb85a74fcdbc35c603847cc022 ]
    
    There is no need to call kfree(im_node) when updating element fails,
    because im_node must be NULL. Remove the unnecessary kfree() for
    im_node.
    
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20241206110622.1161752-3-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: 532d6b36b2bf ("bpf: Handle in-place update for full LPM trie correctly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bc31abdc7c0fcd7a1f9ee47e357fc087e5237cc
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Dec 6 19:06:16 2024 +0800

    bpf: Handle BPF_EXIST and BPF_NOEXIST for LPM trie
    
    [ Upstream commit eae6a075e9537dd69891cf77ca5a88fa8a28b4a1 ]
    
    Add the currently missing handling for the BPF_EXIST and BPF_NOEXIST
    flags. These flags can be specified by users and are relevant since LPM
    trie supports exact matches during update.
    
    Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation")
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20241206110622.1161752-4-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68fc3da03cc453e45df6c1c9e2afd05a87d85946
Author: Jakob Hauser <jahau@rocketmail.com>
Date:   Fri Nov 29 22:25:07 2024 +0100

    iio: magnetometer: yas530: use signed integer type for clamp limits
    
    [ Upstream commit f1ee5483e40881d8ad5a63aa148b753b5c6a839b ]
    
    In the function yas537_measure() there is a clamp_val() with limits of
    -BIT(13) and BIT(13) - 1.  The input clamp value h[] is of type s32.  The
    BIT() is of type unsigned long integer due to its define in
    include/vdso/bits.h.  The lower limit -BIT(13) is recognized as -8192 but
    expressed as an unsigned long integer.  The size of an unsigned long
    integer differs between 32-bit and 64-bit architectures.  Converting this
    to type s32 may lead to undesired behavior.
    
    Additionally, in the calculation lines h[0], h[1] and h[2] the unsigned
    long integer divisor BIT(13) causes an unsigned division, shifting the
    left-hand side of the equation back and forth, possibly ending up in large
    positive values instead of negative values on 32-bit architectures.
    
    To solve those two issues, declare a signed integer with a value of
    BIT(13).
    
    There is another omission in the clamp line: clamp_val() returns a value
    and it's going nowhere here.  Self-assign it to h[i] to make use of the
    clamp macro.
    
    Finally, replace clamp_val() macro by clamp() because after changing the
    limits from type unsigned long integer to signed integer it's fine that
    way.
    
    Link: https://lkml.kernel.org/r/11609b2243c295d65ab4d47e78c239d61ad6be75.1732914810.git.jahau@rocketmail.com
    Fixes: 65f79b501030 ("iio: magnetometer: yas530: Add YAS537 variant")
    Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411230458.dhZwh3TT-lkp@intel.com/
    Closes: https://lore.kernel.org/oe-kbuild-all/202411282222.oF0B4110-lkp@intel.com/
    Reviewed-by: David Laight <david.laight@aculab.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2939c05efba9bf293f8c1e0cf74cba263623583b
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Nov 29 18:24:06 2024 -0800

    scatterlist: fix incorrect func name in kernel-doc
    
    [ Upstream commit d89c8ec0546184267cb211b579514ebaf8916100 ]
    
    Fix a kernel-doc warning by making the kernel-doc function description
    match the function name:
    
    include/linux/scatterlist.h:323: warning: expecting prototype for sg_unmark_bus_address(). Prototype was for sg_dma_unmark_bus_address() instead
    
    Link: https://lkml.kernel.org/r/20241130022406.537973-1-rdunlap@infradead.org
    Fixes: 42399301203e ("lib/scatterlist: add flag for indicating P2PDMA segments in an SGL")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Logan Gunthorpe <logang@deltatee.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67c2c6d0564ca05348ba4f8f6eaf7a0713f56c15
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sat Nov 23 22:28:34 2024 +0900

    ocfs2: free inode when ocfs2_get_init_inode() fails
    
    [ Upstream commit 965b5dd1894f4525f38c1b5f99b0106a07dbb5db ]
    
    syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826
    ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when
    new_inode() succeeded and dquot_initialize() failed.
    
    Link: https://lkml.kernel.org/r/e68c0224-b7c6-4784-b4fa-a9fc8c675525@I-love.SAKURA.ne.jp
    Fixes: 9c89fe0af826 ("ocfs2: Handle error from dquot_initialize()")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot+0af00f6a2cba2058b5db@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0af00f6a2cba2058b5db
    Tested-by: syzbot+0af00f6a2cba2058b5db@syzkaller.appspotmail.com
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5abef60d14818a1d0e24f22bc58d1923eb40b082
Author: Maíra Canal <mcanal@igalia.com>
Date:   Wed Dec 4 09:28:31 2024 -0300

    drm/v3d: Enable Performance Counters before clearing them
    
    [ Upstream commit c98b10496b2f3c4f576af3482c71aadcfcbf765e ]
    
    On the Raspberry Pi 5, performance counters are not being cleared
    when `v3d_perfmon_start()` is called, even though we write to the
    CLR register. As a result, their values accumulate until they
    overflow.
    
    The expected behavior is for performance counters to reset to zero
    at the start of a job. When the job finishes and the perfmon is
    stopped, the counters should accurately reflect the values for that
    specific job.
    
    To ensure this behavior, the performance counters are now enabled
    before being cleared. This allows the CLR register to function as
    intended, zeroing the counter values when the job begins.
    
    Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace")
    Signed-off-by: Maíra Canal <mcanal@igalia.com>
    Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241204122831.17015-1-mcanal@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 907362d4c4f74cf092f740e4762a4ab54f9caeb5
Author: John Garry <john.g.garry@oracle.com>
Date:   Mon Dec 2 13:00:45 2024 +0000

    scsi: scsi_debug: Fix hrtimer support for ndelay
    
    [ Upstream commit 6918141d815acef056a0d10e966a027d869a922d ]
    
    Since commit 771f712ba5b0 ("scsi: scsi_debug: Fix cmd duration
    calculation"), ns_from_boot value is only evaluated in schedule_resp()
    for polled requests.
    
    However, ns_from_boot is also required for hrtimer support for when
    ndelay is less than INCLUSIVE_TIMING_MAX_NS, so fix up the logic to
    decide when to evaluate ns_from_boot.
    
    Fixes: 771f712ba5b0 ("scsi: scsi_debug: Fix cmd duration calculation")
    Signed-off-by: John Garry <john.g.garry@oracle.com>
    Link: https://lore.kernel.org/r/20241202130045.2335194-1-john.g.garry@oracle.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 373d55a47dc662e5e30d12ad5d334312f757c1f1
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Thu Nov 28 16:38:17 2024 +0800

    spi: mpc52xx: Add cancel_work_sync before module remove
    
    [ Upstream commit 984836621aad98802d92c4a3047114cf518074c8 ]
    
    If we remove the module which will call mpc52xx_spi_remove
    it will free 'ms' through spi_unregister_controller.
    while the work ms->work will be used. The sequence of operations
    that may lead to a UAF bug.
    
    Fix it by ensuring that the work is canceled before proceeding with
    the cleanup in mpc52xx_spi_remove.
    
    Fixes: ca632f556697 ("spi: reorganize drivers")
    Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
    Link: https://patch.msgid.link/1f16f8ae0e50ca9adb1dc849bf2ac65a40c9ceb9.1732783000.git.xiaopei01@kylinos.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 935ac3d5175df08198073b31be0e13fb13704626
Author: Björn Töpel <bjorn@rivosinc.com>
Date:   Wed Nov 27 11:17:46 2024 +0100

    tools: Override makefile ARCH variable if defined, but empty
    
    [ Upstream commit 537a2525eaf76ea9b0dca62b994500d8670b39d5 ]
    
    There are a number of tools (bpftool, selftests), that require a
    "bootstrap" build. Here, a bootstrap build is a build host variant of
    a target. E.g., assume that you're performing a bpftool cross-build on
    x86 to riscv, a bootstrap build would then be an x86 variant of
    bpftool. The typical way to perform the host build variant, is to pass
    "ARCH=" in a sub-make. However, if a variable has been set with a
    command argument, then ordinary assignments in the makefile are
    ignored.
    
    This side-effect results in that ARCH, and variables depending on ARCH
    are not set. Workaround by overriding ARCH to the host arch, if ARCH
    is empty.
    
    Fixes: 8859b0da5aac ("tools/bpftool: Fix cross-build")
    Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Reviewed-by: Namhyung Kim <namhyung@kernel.org>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Link: https://lore.kernel.org/bpf/20241127101748.165693-1-bjorn@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c28274b2dccdcf2fe29ef625f3c5f8a09e2b809
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 28 09:04:16 2024 +0100

    ALSA: usb-audio: Notify xrun for low-latency mode
    
    [ Upstream commit 4f9d674377d090e38d93360bd4df21b67534d622 ]
    
    The low-latency mode of USB-audio driver uses a similar approach like
    the implicit feedback mode but it has an explicit queuing at the
    trigger start time.  The difference is, however, that no packet will
    be handled any longer after all queued packets are handled but no
    enough data is fed.  In the case of implicit feedback mode, the
    capture-side packet handling triggers the re-queuing, and this checks
    the XRUN.  OTOH, in the low-latency mode, it just stops without XRUN
    notification unless any new action is taken from user-space via ack
    callback.  For example, when you stop the stream in aplay, no XRUN is
    reported.
    
    This patch adds the XRUN check at the packet complete callback in the
    case all pending URBs are exhausted.  Strictly speaking, this state
    doesn't match really with XRUN; in theory the application may queue
    immediately after this happens.  But such behavior is only for
    1-period configuration, which the USB-audio driver doesn't support.
    So we may conclude that this situation leads certainly to XRUN.
    
    A caveat is that the XRUN should be triggered only for the PCM RUNNING
    state, and not during DRAINING.  This additional state check is put in
    notify_xrun(), too.
    
    Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
    Reported-by: Leonard Crestez <cdleonard@gmail.com>
    Link: https://lore.kernel.org/25d5b0d8-4efd-4630-9d33-7a9e3fa9dc2b@gmail.com
    Link: https://patch.msgid.link/20241128080446.1181-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 456f08d24afa51b5eb816c42e4ca1c44a247bd42
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Oct 16 23:48:38 2024 +0000

    tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
    
    [ Upstream commit ca70b8baf2bd125b2a4d96e76db79375c07d7ff2 ]
    
    The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
    tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.
    
    Potential problems with this strategy are as follows:
    
    - If the actual sent bytes are smaller than tosend, we need to charge some
      bytes back, as in line 487, which is okay but seems not clean.
    
    - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may
      miss uncharging (msg->sg.size - apply_bytes) bytes.
    
    [...]
    415 tosend = msg->sg.size;
    416 if (psock->apply_bytes && psock->apply_bytes < tosend)
    417   tosend = psock->apply_bytes;
    [...]
    443 sk_msg_return(sk, msg, tosend);
    444 release_sock(sk);
    446 origsize = msg->sg.size;
    447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,
    448                             msg, tosend, flags);
    449 sent = origsize - msg->sg.size;
    [...]
    454 lock_sock(sk);
    455 if (unlikely(ret < 0)) {
    456   int free = sk_msg_free_nocharge(sk, msg);
    458   if (!cork)
    459     *copied -= free;
    460 }
    [...]
    487 if (eval == __SK_REDIRECT)
    488   sk_mem_charge(sk, tosend - sent);
    [...]
    
    When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,
    the following warning will be reported:
    
    ------------[ cut here ]------------
    WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0
    Modules linked in:
    CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
    Workqueue: events sk_psock_destroy
    RIP: 0010:inet_sock_destruct+0x190/0x1a0
    RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206
    RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800
    RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900
    RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0
    R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400
    R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100
    FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
    <TASK>
    ? __warn+0x89/0x130
    ? inet_sock_destruct+0x190/0x1a0
    ? report_bug+0xfc/0x1e0
    ? handle_bug+0x5c/0xa0
    ? exc_invalid_op+0x17/0x70
    ? asm_exc_invalid_op+0x1a/0x20
    ? inet_sock_destruct+0x190/0x1a0
    __sk_destruct+0x25/0x220
    sk_psock_destroy+0x2b2/0x310
    process_scheduled_works+0xa3/0x3e0
    worker_thread+0x117/0x240
    ? __pfx_worker_thread+0x10/0x10
    kthread+0xcf/0x100
    ? __pfx_kthread+0x10/0x10
    ret_from_fork+0x31/0x40
    ? __pfx_kthread+0x10/0x10
    ret_from_fork_asm+0x1a/0x30
    </TASK>
    ---[ end trace 0000000000000000 ]---
    
    In __SK_REDIRECT, a more concise way is delaying the uncharging after sent
    bytes are finalized, and uncharge this value. When (ret < 0), we shall
    invoke sk_msg_free.
    
    Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,
    we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same
    warning will be reported in selftest.
    
    [...]
    468 case __SK_DROP:
    469 default:
    470 sk_msg_free_partial(sk, msg, tosend);
    471 sk_msg_apply_bytes(psock, tosend);
    472 *copied -= (tosend + delta);
    473 return -EACCES;
    [...]
    
    So instead of sk_msg_free_partial we can do sk_msg_free here.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Fixes: 8ec95b94716a ("bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/bpf/20241016234838.3167769-3-zijianzhang@bytedance.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f51eb88c39a0f4110f0f4352866c403e08262e8
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Wed Nov 20 15:21:36 2024 +0800

    drm/sti: Add __iomem for mixer_dbg_mxn's parameter
    
    [ Upstream commit 86e8f94789dd6f3e705bfa821e1e416f97a2f863 ]
    
    Sparse complains about incorrect type in argument 1.
    expected void const volatile  __iomem *ptr but got void *.
    so modify mixer_dbg_mxn's addr parameter.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202411191809.6V3c826r-lkp@intel.com/
    Fixes: a5f81078a56c ("drm/sti: add debugfs entries for MIXER crtc")
    Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
    Acked-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/c28f0dcb6a4526721d83ba1f659bba30564d3d54.1732087094.git.xiaopei01@kylinos.cn
    Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31a19580badbaa67837fafc31b892ea08009a31a
Author: Amir Mohammadi <amirmohammadi1999.am@gmail.com>
Date:   Thu Nov 21 12:04:13 2024 +0330

    bpftool: fix potential NULL pointer dereferencing in prog_dump()
    
    [ Upstream commit ef3ba8c258ee368a5343fa9329df85b4bcb9e8b5 ]
    
    A NULL pointer dereference could occur if ksyms
    is not properly checked before usage in the prog_dump() function.
    
    Fixes: b053b439b72a ("bpf: libbpf: bpftool: Print bpf_line_info during prog dump")
    Signed-off-by: Amir Mohammadi <amiremohamadi@yahoo.com>
    Reviewed-by: Quentin Monnet <qmo@kernel.org>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241121083413.7214-1-amiremohamadi@yahoo.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7a289f3e3f29b8518fd42cd81e261dca4f1e6fa
Author: Quentin Monnet <qmo@kernel.org>
Date:   Tue Oct 25 16:03:23 2022 +0100

    bpftool: Remove asserts from JIT disassembler
    
    [ Upstream commit 55b4de58d0e2aca810ed2b198a0173640300acf8 ]
    
    The JIT disassembler in bpftool is the only components (with the JSON
    writer) using asserts to check the return values of functions. But it
    does not do so in a consistent way, and diasm_print_insn() returns no
    value, although sometimes the operation failed.
    
    Remove the asserts, and instead check the return values, print messages
    on errors, and propagate the error to the caller from prog.c.
    
    Remove the inclusion of assert.h from jit_disasm.c, and also from map.c
    where it is unused.
    
    Signed-off-by: Quentin Monnet <quentin@isovalent.com>
    Tested-by: Niklas Söderlund <niklas.soderlund@corigine.com>
    Acked-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20221025150329.97371-3-quentin@isovalent.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: ef3ba8c258ee ("bpftool: fix potential NULL pointer dereferencing in prog_dump()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98452de4519083cb12ec453b5ea61c681cfed2c1
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Fri Nov 22 12:29:09 2024 +0100

    xsk: always clear DMA mapping information when unmapping the pool
    
    [ Upstream commit ac9a48a6f1610b094072b815e884e1668aea4401 ]
    
    When the umem is shared, the DMA mapping is also shared between the xsk
    pools, therefore it should stay valid as long as at least 1 user remains.
    However, the pool also keeps the copies of DMA-related information that are
    initialized in the same way in xp_init_dma_info(), but cleared by
    xp_dma_unmap() only for the last remaining pool, this causes the problems
    below.
    
    The first one is that the commit adbf5a42341f ("ice: remove af_xdp_zc_qps
    bitmap") relies on pool->dev to determine the presence of a ZC pool on a
    given queue, avoiding internal bookkeeping. This works perfectly fine if
    the UMEM is not shared, but reliably fails otherwise as stated in the
    linked report.
    
    The second one is pool->dma_pages which is dynamically allocated and
    only freed in xp_dma_unmap(), this leads to a small memory leak. kmemleak
    does not catch it, but by printing the allocation results after terminating
    the userspace program it is possible to see that all addresses except the
    one belonging to the last detached pool are still accessible through the
    kmemleak dump functionality.
    
    Always clear the DMA mapping information from the pool and free
    pool->dma_pages when unmapping the pool, so that the only difference
    between results of the last remaining user's call and the ones before would
    be the destruction of the DMA mapping.
    
    Fixes: adbf5a42341f ("ice: remove af_xdp_zc_qps bitmap")
    Fixes: 921b68692abb ("xsk: Enable sharing of dma mappings")
    Reported-by: Alasdair McWilliam <alasdair.mcwilliam@outlook.com>
    Closes: https://lore.kernel.org/PA4P194MB10056F208AF221D043F57A3D86512@PA4P194MB1005.EURP194.PROD.OUTLOOK.COM
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Link: https://lore.kernel.org/r/20241122112912.89881-1-larysa.zaremba@intel.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ba1e05536b7580b60338339582656d8617bd6a5
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue Oct 29 17:54:10 2024 +0800

    drm/bridge: it6505: Fix inverted reset polarity
    
    [ Upstream commit c5f3f21728b069412e8072b8b1d0a3d9d3ab0265 ]
    
    The IT6505 bridge chip has a active low reset line. Since it is a
    "reset" and not an "enable" line, the GPIO should be asserted to
    put it in reset and deasserted to bring it out of reset during
    the power on sequence.
    
    The polarity was inverted when the driver was first introduced, likely
    because the device family that was targeted had an inverting level
    shifter on the reset line.
    
    The MT8186 Corsola devices already have the IT6505 in their device tree,
    but the whole display pipeline is actually disabled and won't be enabled
    until some remaining issues are sorted out. The other known user is
    the MT8183 Kukui / Jacuzzi family; their device trees currently do not
    have the IT6505 included.
    
    Fix the polarity in the driver while there are no actual users.
    
    Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241029095411.657616-1-wenst@chromium.org
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39d3bb22a869fbd8eb747301211887dc39a6d8b8
Author: Kuro Chung <kuro.chung@ite.com.tw>
Date:   Tue Jun 4 10:44:05 2024 +0800

    drm/bridge: it6505: update usleep_range for RC circuit charge time
    
    [ Upstream commit 8814444e62b8a8b573fba2cbbb327d5817b74eb0 ]
    
    The spec of timing between IVDD/OVDD and SYSRTEN is 10ms, but SYSRSTN RC
    circuit need at least 25ms for rising time, update for match spec
    
    Signed-off-by: Kuro Chung <kuro.chung@ite.com.tw>
    Signed-off-by: Hermes Wu <hermes.wu@ite.com.tw>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240604024405.1122488-1-kuro.chung@ite.com.tw
    Stable-dep-of: c5f3f21728b0 ("drm/bridge: it6505: Fix inverted reset polarity")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28a01c6b3f18e22a3d40b04faece8b6896c25e8b
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Fri Sep 27 01:20:52 2024 +0200

    leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths
    
    [ Upstream commit 73b03b27736e440e3009fe1319cbc82d2cd1290c ]
    
    The device_for_each_child_node() macro requires explicit calls to
    fwnode_handle_put() upon early exits to avoid memory leaks, and in
    this case the error paths are handled after jumping to
    'out_flash_realease', which misses that required call to
    to decrement the refcount of the child node.
    
    A more elegant and robust solution is using the scoped variant of the
    loop, which automatically handles such early exits.
    
    Fix the child node refcounting in the error paths by using
    device_for_each_child_node_scoped().
    
    Cc: stable@vger.kernel.org
    Fixes: 679f8652064b ("leds: Add mt6360 driver")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-1-95c0614b38c8@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fedf3dc30e8584018987fedf4b74c19d82df807
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat Feb 17 16:42:38 2024 +0000

    device property: Introduce device_for_each_child_node_scoped()
    
    [ Upstream commit 365130fd47af6d4317aa16a407874b699ab8d8cb ]
    
    Similar to recently propose for_each_child_of_node_scoped() this
    new version of the loop macro instantiates a new local
    struct fwnode_handle * that uses the __free(fwnode_handle) auto
    cleanup handling so that if a reference to a node is held on early
    exit from the loop the reference will be released. If the loop
    runs to completion, the child pointer will be NULL and no action will
    be taken.
    
    The reason this is useful is that it removes the need for
    fwnode_handle_put() on early loop exits.  If there is a need
    to retain the reference, then return_ptr(child) or no_free_ptr(child)
    may be used to safely disable the auto cleanup.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240217164249.921878-5-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 73b03b27736e ("leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da1097f8d9398b49b3c44cfab517a169266692e8
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat Feb 17 16:42:36 2024 +0000

    device property: Add cleanup.h based fwnode_handle_put() scope based cleanup.
    
    [ Upstream commit 59ed5e2d505bf5f9b4af64d0021cd0c96aec1f7c ]
    
    Useful where the fwnode_handle was obtained from a call such as
    fwnode_find_reference() as it will safely do nothing if IS_ERR() is true
    and will automatically release the reference on the variable leaving
    scope.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240217164249.921878-3-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 73b03b27736e ("leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ba045ab08a9ce14643e60e6a349903777059bdb
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Oct 4 12:21:28 2022 +0300

    device property: Constify device child node APIs
    
    [ Upstream commit 7952cd2b8213f20a1752634c25dfd215da537722 ]
    
    The device parameter is not altered in the device child node APIs,
    constify them.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Link: https://lore.kernel.org/r/20221004092129.19412-5-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 73b03b27736e ("leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c2a6d4d020c38450e8b3a7b932f21289ace2777
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Thu Nov 7 08:53:09 2024 +0800

    PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf()
    
    [ Upstream commit 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 ]
    
    In addition to a primary endpoint controller, an endpoint function may be
    associated with a secondary endpoint controller, epf->sec_epc, to provide
    NTB (non-transparent bridge) functionality.
    
    Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of
    epf->sec_epc when removing from the secondary endpoint controller.
    
    Extend the epc->list_lock coverage and clear either epf->epc or
    epf->sec_epc as indicated.
    
    Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com
    Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF")
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    [bhelgaas: commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9102582762011051847fcb6d78c97068ebf707f1
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Tue Jan 24 12:41:56 2023 +0530

    PCI: endpoint: Use a separate lock for protecting epc->pci_epf list
    
    [ Upstream commit d6dd5bafaabf98a99a76227ab8dc9a89e76a198f ]
    
    The EPC controller maintains a list of EPF drivers added to it. For
    protecting this list against the concurrent accesses, the epc->lock
    (used for protecting epc_ops) has been used so far. Since there were
    no users trying to use epc_ops and modify the pci_epf list simultaneously,
    this was not an issue.
    
    But with the addition of callback mechanism for passing the events, this
    will be a problem. Because the pci_epf list needs to be iterated first
    for getting hold of the EPF driver and then the relevant event specific
    callback needs to be called for the driver.
    
    If the same epc->lock is used, then it will result in a deadlock scenario.
    
    For instance,
    
    ...
            mutex_lock(&epc->lock);
            list_for_each_entry(epf, &epc->pci_epf, list) {
                    epf->event_ops->core_init(epf);
                    |
                    |-> pci_epc_set_bar();
                            |
                            |-> mutex_lock(&epc->lock) # DEADLOCK
    ...
    
    So to fix this issue, use a separate lock called "list_lock" for
    protecting the pci_epf list against the concurrent accesses. This lock
    will also be used by the callback mechanism.
    
    Link: https://lore.kernel.org/linux-pci/20230124071158.5503-4-manivannan.sadhasivam@linaro.org
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
    Stable-dep-of: 688d2eb4c6fc ("PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c77c55f459b2088a5115706f1d5662d3205cba4
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Oct 21 11:45:08 2024 -0400

    i3c: master: Fix dynamic address leak when 'assigned-address' is present
    
    [ Upstream commit 851bd21cdb55e727ab29280bc9f6b678164f802a ]
    
    If the DTS contains 'assigned-address', a dynamic address leak occurs
    during hotjoin events.
    
    Assume a device have assigned-address 0xb.
      - Device issue Hotjoin
      - Call i3c_master_do_daa()
      - Call driver xxx_do_daa()
      - Call i3c_master_get_free_addr() to get dynamic address 0x9
      - i3c_master_add_i3c_dev_locked(0x9)
      -     expected_dyn_addr  = newdev->boardinfo->init_dyn_addr (0xb);
      -     i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9));
      -         if (dev->info.dyn_addr != old_dyn_addr &&
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE
                    (!dev->boardinfo ||
                     ^^^^^^^^^^^^^^^ ->  FALSE
                     dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) {
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     0xb != 0xb      ->  FALSE
                     ...
                     i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr,
                                                         I3C_ADDR_SLOT_FREE);
                     ^^^
                     This will be skipped. So old_dyn_addr never free
                }
    
      - i3c_master_get_free_addr() will return increased sequence number.
    
    Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check.
    dev->info.dyn_addr should be checked before calling this function because
    i3c_master_setnewda_locked() has already been called and the target device
    has already accepted dyn_addr. It is too late to check if dyn_addr is free
    in i3c_master_reattach_i3c_dev().
    
    Add check to ensure expected_dyn_addr is free before
    i3c_master_setnewda_locked().
    
    Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process")
    Cc: stable@kernel.org
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 432b68842495179df2bb6f860343e3a22930b710
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Oct 21 11:45:07 2024 -0400

    i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED
    
    [ Upstream commit 2f552fa280590e61bd3dbe66a7b54b99caa642a4 ]
    
    Extend the address status bit to 4 and introduce the
    I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a
    specific address. This is generally set by the 'assigned-address' in the
    device tree source (dts) file.
    
     ┌────┬─────────────┬───┬─────────┬───┐
     │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA  │ T ├────┐
     └────┴─────────────┴───┴─────────┴───┘    │
     ┌─────────────────────────────────────────┘
     │  ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐
     └─►│Sr│7'h7E RnW=1  │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│
        └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘
    
    Some master controllers (such as HCI) need to prepare the entire above
    transaction before sending it out to the I3C bus. This means that a 7-bit
    dynamic address needs to be allocated before knowing the target device's
    UID information.
    
    However, some I3C targets may request specific addresses (called as
    "init_dyn_addr"), which is typically specified by the DT-'s
    assigned-address property. Lower addresses having higher IBI priority. If
    it is available, i3c_bus_get_free_addr() preferably return a free address
    that is not in the list of desired addresses (called as "init_dyn_addr").
    This allows the device with the "init_dyn_addr" to switch to its
    "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the
    "init_dyn_addr" is already in use by another I3C device, the target device
    will not be able to switch to its desired address.
    
    If the previous step fails, fallback returning one of the remaining
    unassigned address, regardless of its state in the desired list.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 851bd21cdb55 ("i3c: master: Fix dynamic address leak when 'assigned-address' is present")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e195da0610b988aba0389aeb7d3a30bbb0207d60
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Oct 21 11:45:06 2024 -0400

    i3c: master: Replace hard code 2 with macro I3C_ADDR_SLOT_STATUS_BITS
    
    [ Upstream commit 16aed0a6520ba01b7d22c32e193fc1ec674f92d4 ]
    
    Replace the hardcoded value 2, which indicates 2 bits for I3C address
    status, with the predefined macro I3C_ADDR_SLOT_STATUS_BITS.
    
    Improve maintainability and extensibility of the code.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-1-4098b8bde01e@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 851bd21cdb55 ("i3c: master: Fix dynamic address leak when 'assigned-address' is present")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d636e0934979690836ea111f160d43705038568
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Nov 1 12:50:02 2024 -0400

    i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter
    
    [ Upstream commit 25bc99be5fe53853053ceeaa328068c49dc1e799 ]
    
    Fix issue where disabling IBI on one device disables the entire IBI
    interrupt. Modify bit 7:0 of enabled_events to serve as an IBI enable
    counter, ensuring that the system IBI interrupt is disabled only when all
    I3C devices have IBI disabled.
    
    Cc: stable@kernel.org
    Fixes: 7ff730ca458e ("i3c: master: svc: enable the interrupt in the enable ibi function")
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241101165002.2479794-1-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9530ad77c2c0a569b99b6806e340e16805987000
Author: Carlos Song <carlos.song@nxp.com>
Date:   Tue Sep 10 13:16:26 2024 +0800

    i3c: master: svc: use slow speed for first broadcast address
    
    [ Upstream commit 20ade67bb1645f5ce8f37fa79ddfebbc5b5b24ef ]
    
    I3C controller should support adjusting open drain timing for the first
    broadcast address to make I3C device working as a i2c device can see slow
    broadcast address to close its Spike Filter to change working at i3c mode.
    
    Signed-off-by: Carlos Song <carlos.song@nxp.com>
    Reviewed-by: Frank Li <frank.li@nxp.com>
    Link: https://lore.kernel.org/r/20240910051626.4052552-2-carlos.song@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9be932790520a88fe6c49ad2563310cce2146554
Author: Carlos Song <carlos.song@nxp.com>
Date:   Tue Sep 10 13:16:25 2024 +0800

    i3c: master: support to adjust first broadcast address speed
    
    [ Upstream commit aef79e189ba2b32f78bd35daf2c0b41f3868a321 ]
    
    According to I3C spec 6.2 Timing Specification, the Open Drain High Period
    of SCL Clock timing for first broadcast address should be adjusted to 200ns
    at least. I3C device working as i2c device will see the broadcast to close
    its Spike Filter then change to work at I3C mode. After that I3C open drain
    SCL high level should be adjusted back.
    
    Signed-off-by: Carlos Song <carlos.song@nxp.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240910051626.4052552-1-carlos.song@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c135c0a52d75d2914dbe444bd3338daa70cacdf
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Jan 9 00:25:48 2024 -0500

    i3c: master: fix kernel-doc check warning
    
    [ Upstream commit 34d946b723b53488ab39d8ac540ddf9db255317a ]
    
    Fix warning found by
            'scripts/kernel-doc -v -none include/linux/i3c/master.h'
    
    include/linux/i3c/master.h:457: warning: Function parameter or member 'enable_hotjoin' not described in 'i3c_master_controller_ops'
    include/linux/i3c/master.h:457: warning: Function parameter or member 'disable_hotjoin' not described in 'i3c_master_controller_ops'
    include/linux/i3c/master.h:499: warning: Function parameter or member 'hotjoin' not described in 'i3c_master_controller'
    
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20240109052548.2128133-1-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d4fffb144a1b4cb29398946094b9ae4487bb1db
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Dec 1 17:25:28 2023 -0500

    i3c: master: svc: add hot join support
    
    [ Upstream commit 05b26c31a4859af9e75b7de77458e99358364fe1 ]
    
    Add hot join support for svc master controller. Disable hot join by
    default.
    User can use sysfs entry to enable hot join.
    
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20231201222532.2431484-3-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fa1dfad77901af8946f737b566e553707f8fb19
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Dec 1 17:25:27 2023 -0500

    i3c: master: add enable(disable) hot join in sys entry
    
    [ Upstream commit 317bacf960a4879af22d12175f47d284930b3273 ]
    
    Add hotjoin entry in sys file system allow user enable/disable hotjoin
    feature.
    
    Add (*enable(disable)_hotjoin)() to i3c_master_controller_ops.
    Add api i3c_master_enable(disable)_hotjoin();
    
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20231201222532.2431484-2-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87e0f28eda36c7843523aa8dd0c5dab3331e9718
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Mar 19 00:33:07 2023 +0100

    i3c: Make i3c_master_unregister() return void
    
    [ Upstream commit 0f74f8b6675cc36d689abb4d9b3d75ab4049b7d7 ]
    
    The function returned zero unconditionally. Switch the return type to void
    and simplify the callers accordingly.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20230318233311.265186-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c74e733b96117ffe452af4fc60d12792bec22e66
Author: Saravana Kannan <saravanak@google.com>
Date:   Wed Oct 30 10:10:07 2024 -0700

    driver core: fw_devlink: Stop trying to optimize cycle detection logic
    
    [ Upstream commit bac3b10b78e54b7da3cede397258f75a2180609b ]
    
    In attempting to optimize fw_devlink runtime, I introduced numerous cycle
    detection bugs by foregoing cycle detection logic under specific
    conditions. Each fix has further narrowed the conditions for optimization.
    
    It's time to give up on these optimization attempts and just run the cycle
    detection logic every time fw_devlink tries to create a device link.
    
    The specific bug report that triggered this fix involved a supplier fwnode
    that never gets a device created for it. Instead, the supplier fwnode is
    represented by the device that corresponds to an ancestor fwnode.
    
    In this case, fw_devlink didn't do any cycle detection because the cycle
    detection logic is only run when a device link is created between the
    devices that correspond to the actual consumer and supplier fwnodes.
    
    With this change, fw_devlink will run cycle detection logic even when
    creating SYNC_STATE_ONLY proxy device links from a device that is an
    ancestor of a consumer fwnode.
    
    Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Closes: https://lore.kernel.org/all/1a1ab663-d068-40fb-8c94-f0715403d276@ideasonboard.com/
    Fixes: 6442d79d880c ("driver core: fw_devlink: Improve detection of overlapping cycles")
    Cc: stable <stable@kernel.org>
    Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Link: https://lore.kernel.org/r/20241030171009.1853340-1-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3284739bbfaf8de51b800006d54f0c9208feaab
Author: Saravana Kannan <saravanak@google.com>
Date:   Mon Mar 4 21:04:55 2024 -0800

    driver core: Add FWLINK_FLAG_IGNORE to completely ignore a fwnode link
    
    [ Upstream commit b7e1241d8f77ed64404a5e4450f43a319310fc91 ]
    
    A fwnode link between specific supplier-consumer fwnodes can be added
    multiple times for multiple reasons. If that dependency doesn't exist,
    deleting the fwnode link once doesn't guarantee that it won't get created
    again.
    
    So, add FWLINK_FLAG_IGNORE flag to mark a fwnode link as one that needs to
    be completely ignored. Since a fwnode link's flags is an OR of all the
    flags passed to all the fwnode_link_add() calls to create that specific
    fwnode link, the FWLINK_FLAG_IGNORE flag is preserved and can be used to
    mark a fwnode link as on that need to be completely ignored until it is
    deleted.
    
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20240305050458.1400667-3-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize cycle detection logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84bdb88f70a8853d8655225b196ea64f66cb2f09
Author: Saravana Kannan <saravanak@google.com>
Date:   Fri Feb 2 01:56:35 2024 -0800

    driver core: fw_devlink: Improve logs for cycle detection
    
    [ Upstream commit 6e7ad1aebb4fc9fed0217dd50ef6e58a53f17d81 ]
    
    The links in a cycle are not all logged in a consistent manner or not
    logged at all. Make them consistent by adding a "cycle:" string and log all
    the link in the cycles (even the child ==> parent dependency) so that it's
    easier to debug cycle detection code. Also, mark the start and end of a
    cycle so it's easy to tell when multiple cycles are logged back to back.
    
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Tested-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20240202095636.868578-4-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize cycle detection logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f24a5f8309438863e57d067d38ab5da7430a156
Author: Marcelo Dalmas <marcelo.dalmas@ge.com>
Date:   Mon Nov 25 12:16:09 2024 +0000

    ntp: Remove invalid cast in time offset math
    
    commit f5807b0606da7ac7c1b74a386b22134ec7702d05 upstream.
    
    Due to an unsigned cast, adjtimex() returns the wrong offest when using
    ADJ_MICRO and the offset is negative. In this case a small negative offset
    returns approximately 4.29 seconds (~ 2^32/1000 milliseconds) due to the
    unsigned cast of the negative offset.
    
    This cast was added when the kernel internal struct timex was changed to
    use type long long for the time offset value to address the problem of a
    64bit/32bit division on 32bit systems.
    
    The correct cast would have been (s32), which is correct as time_offset can
    only be in the range of [INT_MIN..INT_MAX] because the shift constant used
    for calculating it is 32. But that's non-obvious.
    
    Remove the cast and use div_s64() to cure the issue.
    
    [ tglx: Fix white space damage, use div_s64() and amend the change log ]
    
    Fixes: ead25417f82e ("timex: use __kernel_timex internally")
    Signed-off-by: Marcelo Dalmas <marcelo.dalmas@ge.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/SJ0P101MB03687BF7D5A10FD3C49C51E5F42E2@SJ0P101MB0368.NAMP101.PROD.OUTLOOK.COM
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c013fde1c7612b28caf3055710ec9d53d29bae2
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Oct 30 11:41:37 2024 -0700

    powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang
    
    [ Upstream commit d677ce521334d8f1f327cafc8b1b7854b0833158 ]
    
    Under certain conditions, the 64-bit '-mstack-protector-guard' flags may
    end up in the 32-bit vDSO flags, resulting in build failures due to the
    structure of clang's argument parsing of the stack protector options,
    which validates the arguments of the stack protector guard flags
    unconditionally in the frontend, choking on the 64-bit values when
    targeting 32-bit:
    
      clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2
      clang: error: invalid value 'r13' in 'mstack-protector-guard-reg=', expected one of: r2
      make[3]: *** [arch/powerpc/kernel/vdso/Makefile:85: arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1
      make[3]: *** [arch/powerpc/kernel/vdso/Makefile:87: arch/powerpc/kernel/vdso/vgetrandom-32.o] Error 1
    
    Remove these flags by adding them to the CC32FLAGSREMOVE variable, which
    already handles situations similar to this. Additionally, reformat and
    align a comment better for the expanding CONFIG_CC_IS_CLANG block.
    
    Cc: stable@vger.kernel.org # v6.1+
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030-powerpc-vdso-drop-stackp-flags-clang-v1-1-d95e7376d29c@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b015f065276797b1e5675525c6f697bead776d5
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Sep 2 21:17:20 2024 +0200

    powerpc/vdso: Refactor CFLAGS for CVDSO build
    
    [ Upstream commit a6b67eb09963af29991625862cbb4f56b85954ed ]
    
    In order to avoid two much duplication when we add new VDSO
    functionnalities in C like getrandom, refactor common CFLAGS.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4ccf8ec27613262fbb5966979e11cdc8117463d
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Jun 1 11:46:33 2023 -0700

    powerpc/vdso: Include CLANG_FLAGS explicitly in ldflags-y
    
    [ Upstream commit a7e5eb53bf9b800d086e2ebcfebd9a3bb16bd1b0 ]
    
    A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to
    KBUILD_CPPFLAGS so that '--target' is available while preprocessing.
    When that occurs, the following error appears when building the compat
    PowerPC vDSO:
    
      clang: error: unsupported option '-mbig-endian' for target 'x86_64-pc-linux-gnu'
      make[3]: *** [.../arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/vdso32.so.dbg] Error 1
    
    Explicitly add CLANG_FLAGS to ldflags-y, so that '--target' will always
    be present.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1234c16941e824585dc9434b314b1072af0e07ac
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 11 20:05:05 2023 -0700

    powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with clang
    
    [ Upstream commit 05e05bfc92d196669a3d087fc34d3998b6ddb758 ]
    
    When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
    warns:
    
      clang-16: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument]
    
    This warning happens because vgettimeofday-32.c gets its base CFLAGS
    from the main kernel, which may contain flags that are only supported on
    a 64-bit target but not a 32-bit one, which is the case here.
    -fstack-clash-protection and its negation are only suppported by the
    64-bit powerpc target but that flag is included in an invocation for a
    32-bit powerpc target, so clang points out that while the flag is one
    that it recognizes, it is not actually used by this compiler job.
    
    To eliminate the warning, remove -fno-stack-clash-protection from
    vgettimeofday-32.c's CFLAGS when using clang, as has been done for other
    flags previously.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d1d3940eff1bc0a62d6940eac865069a113fad9
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 11 20:05:04 2023 -0700

    powerpc/vdso: Improve linker flags
    
    [ Upstream commit f0a42fbab447ed9f55bbd99751183e71f3a1f6ec ]
    
    When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
    are several warnings in the PowerPC vDSO:
    
      clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused [-Werror,-Wunused-command-line-argument]
      clang-16: error: -Wl,--hash-style=both: 'linker' input unused [-Werror,-Wunused-command-line-argument]
      clang-16: error: argument unused during compilation: '-shared' [-Werror,-Wunused-command-line-argument]
    
      clang-16: error: argument unused during compilation: '-nostdinc' [-Werror,-Wunused-command-line-argument]
      clang-16: error: argument unused during compilation: '-Wa,-maltivec' [-Werror,-Wunused-command-line-argument]
    
    The first group of warnings point out that linker flags were being added
    to all invocations of $(CC), even though they will only be used during
    the final vDSO link. Move those flags to ldflags-y.
    
    The second group of warnings are compiler or assembler flags that will
    be unused during linking. Filter them out from KBUILD_CFLAGS so that
    they are not used during linking.
    
    Additionally, '-z noexecstack' was added directly to the ld_and_check
    rule in commit 1d53c0192b15 ("powerpc/vdso: link with -z noexecstack")
    but now that there is a common ldflags variable, it can be moved there.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a911a321573285a0eec2b85d1fd6c1abb77fd802
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 11 20:05:03 2023 -0700

    powerpc/vdso: Remove unused '-s' flag from ASFLAGS
    
    [ Upstream commit 024734d132846dcb27f07deb1ec5be64d4cbfae9 ]
    
    When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
    warns:
    
      clang-16: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument]
    
    The compiler's '-s' flag is a linking option (it is passed along to the
    linker directly), which means it does nothing when the linker is not
    invoked by the compiler. The kernel builds all .o files with '-c', which
    stops the compilation pipeline before linking, so '-s' can be safely
    dropped from ASFLAGS.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Anders Roxell <anders.roxell@linaro.org>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1747a559aa9ce59913a4f03c62bf85c9f9f140ff
Author: Sathvika Vasireddy <sv@linux.ibm.com>
Date:   Mon Nov 14 23:27:45 2022 +0530

    powerpc/vdso: Skip objtool from running on VDSO files
    
    [ Upstream commit d0160bd5d389da247fb5affb6a35ea393d22fedb ]
    
    Do not run objtool on VDSO files, by using OBJECT_FILES_NON_STANDARD.
    
    Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221114175754.1131267-8-sv@linux.ibm.com
    Stable-dep-of: d677ce521334 ("powerpc/vdso: Drop -mstack-protector-guard flags in 32-bit files with clang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 749a916a9cd068dab78fbbe9a01f523084a5844c
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Nov 14 01:02:06 2024 +0000

    usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED
    
    [ Upstream commit 5d2fb074dea289c41f5aaf2c3f68286bee370634 ]
    
    The driver cannot issue the End Transfer command to the SETUP transfer.
    Don't clear DWC3_EP_TRANSFER_STARTED flag to make sure that the driver
    won't send Start Transfer command again, which can cause no-resource
    error. For example this can occur if the host issues a reset to the
    device.
    
    Cc: stable@vger.kernel.org
    Fixes: 76cb323f80ac ("usb: dwc3: ep0: clear all EP0 flags")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/d3d618185fd614bb7426352a9fc1199641d3b5f5.1731545781.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68fb250eecc1cd431eadd877253bd1d25bdb58b8
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Thu Aug 15 08:40:29 2024 +0200

    usb: dwc3: ep0: Don't reset resource alloc flag (including ep0)
    
    [ Upstream commit 72fca8371f205d654f95b09cd023a71fd5307041 ]
    
    The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an
    endpoint is only assigned once. Unless the endpoint is reset, don't
    clear this flag. Otherwise we may set endpoint resource again, which
    prevents the driver from initiate transfer after handling a STALL or
    endpoint halt to the control endpoint.
    
    Commit f2e0eee47038 ("usb: dwc3: ep0: Don't reset resource alloc flag")
    was fixing the initial issue, but did this only for physical ep1. Since
    the function dwc3_ep0_stall_and_restart is resetting the flags for both
    physical endpoints, this also has to be done for ep0.
    
    Cc: stable@vger.kernel.org
    Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow")
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Link: https://lore.kernel.org/r/20240814-dwc3hwep0reset-v2-1-29e1d7d923ea@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 5d2fb074dea2 ("usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d60098113d9e3579aecc003149fb77f04d3543cb
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Feb 1 02:26:53 2024 +0000

    usb: dwc3: gadget: Rewrite endpoint allocation flow
    
    [ Upstream commit b311048c174da893f47fc09439bc1f6fa2a29589 ]
    
    The driver dwc3 deviates from the programming guide in regard to
    endpoint configuration. It does this command sequence:
    
    DEPSTARTCFG -> DEPXFERCFG -> DEPCFG
    
    Instead of the suggested flow:
    
    DEPSTARTCFG -> DEPCFG -> DEPXFERCFG
    
    The reasons for this deviation were as follow, quoted:
    
            1) The databook says to do %DWC3_DEPCMD_DEPSTARTCFG for every
               %USB_REQ_SET_CONFIGURATION and %USB_REQ_SET_INTERFACE
               (8.1.5). This is incorrect in the scenario of multiple
               interfaces.
    
            2) The databook does not mention doing more
               %DWC3_DEPCMD_DEPXFERCFG for new endpoint on alt setting
               (8.1.6).
    
    Regarding 1), DEPSTARTCFG resets the endpoints' resource and can be a
    problem if used with SET_INTERFACE request of a multiple interface
    configuration. But we can still satisfy the programming guide
    requirement by assigning the endpoint resource as part of
    usb_ep_enable(). We will only reset endpoint resources on controller
    initialization and SET_CONFIGURATION request.
    
    Regarding 2), the later versions of the programming guide were updated
    to clarify this flow (see "Alternate Initialization on SetInterface
    Request" of the programming guide). As long as the platform has enough
    physical endpoints, we can assign resource to a new endpoint.
    
    The order of the command sequence will not be a problem to most
    platforms for the current implementation of the dwc3 driver. However,
    this order is required in different scenarios (such as initialization
    during controller's hibernation restore). Let's keep the flow consistent
    and follow the programming guide.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/c143583a5afb087deb8c3aa5eb227ee23515f272.1706754219.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 5d2fb074dea2 ("usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc372a2739ee910390fd227f04a73c46e32e5b78
Author: Kartik Rajput <kkartik@nvidia.com>
Date:   Wed Nov 13 14:56:29 2024 +0530

    serial: amba-pl011: Fix RX stall when DMA is used
    
    [ Upstream commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf ]
    
    Function pl011_throttle_rx() calls pl011_stop_rx() to disable RX, which
    also disables the RX DMA by clearing the RXDMAE bit of the DMACR
    register. However, to properly unthrottle RX when DMA is used, the
    function pl011_unthrottle_rx() is expected to set the RXDMAE bit of
    the DMACR register, which it currently lacks. This causes RX to stall
    after the throttle API is called.
    
    Set RXDMAE bit in the DMACR register while unthrottling RX if RX DMA is
    used.
    
    Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5283338fcd2fa0d175fabf2e6386f62c34d1a43a
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Sep 14 20:43:34 2023 +0206

    serial: amba-pl011: Use port lock wrappers
    
    [ Upstream commit 68ca3e72d7463d79d29b6e4961d6028df2a88e25 ]
    
    When a serial port is used for kernel console output, then all
    modifications to the UART registers which are done from other contexts,
    e.g. getty, termios, are interference points for the kernel console.
    
    So far this has been ignored and the printk output is based on the
    principle of hope. The rework of the console infrastructure which aims to
    support threaded and atomic consoles, requires to mark sections which
    modify the UART registers as unsafe. This allows the atomic write function
    to make informed decisions and eventually to restore operational state. It
    also allows to prevent the regular UART code from modifying UART registers
    while printk output is in progress.
    
    All modifications of UART registers are guarded by the UART port lock,
    which provides an obvious synchronization point with the console
    infrastructure.
    
    To avoid adding this functionality to all UART drivers, wrap the
    spin_[un]lock*() invocations for uart_port::lock into helper functions
    which just contain the spin_[un]lock*() invocations for now. In a
    subsequent step these helpers will gain the console synchronization
    mechanisms.
    
    Converted with coccinelle. No functional change.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20230914183831.587273-18-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09adf8792b61c09ae543972a1ece1884ef773848
Author: Charles Han <hanchunchao@inspur.com>
Date:   Thu Nov 14 17:18:22 2024 +0800

    gpio: grgpio: Add NULL check in grgpio_probe
    
    [ Upstream commit 050b23d081da0f29474de043e9538c1f7a351b3b ]
    
    devm_kasprintf() can return a NULL pointer on failure,but this
    returned value in grgpio_probe is not checked.
    Add NULL check in grgpio_probe, to handle kernel NULL
    pointer dereference error.
    
    Cc: stable@vger.kernel.org
    Fixes: 7eb6ce2f2723 ("gpio: Convert to using %pOF instead of full_name")
    Signed-off-by: Charles Han <hanchunchao@inspur.com>
    Link: https://lore.kernel.org/r/20241114091822.78199-1-hanchunchao@inspur.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c942c54a36a6a75c31e52ab15c91d7126efcee52
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Tue Oct 15 15:18:31 2024 +0200

    gpio: grgpio: use a helper variable to store the address of ofdev->dev
    
    [ Upstream commit d036ae41cebdfae92666024163c109b8fef516fa ]
    
    Instead of dereferencing the platform device pointer repeatedly, just
    store its address in a helper variable.
    
    Link: https://lore.kernel.org/r/20241015131832.44678-3-brgl@bgdev.pl
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Stable-dep-of: 050b23d081da ("gpio: grgpio: Add NULL check in grgpio_probe")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6af853cf5f897d55f42e9166f4db50e84e404fb3
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Fri Oct 25 20:31:03 2024 +0000

    KVM: arm64: Don't retire aborted MMIO instruction
    
    [ Upstream commit e735a5da64420a86be370b216c269b5dd8e830e2 ]
    
    Returning an abort to the guest for an unsupported MMIO access is a
    documented feature of the KVM UAPI. Nevertheless, it's clear that this
    plumbing has seen limited testing, since userspace can trivially cause a
    WARN in the MMIO return:
    
      WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
      Call trace:
       kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
       kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133
       kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487
       __do_sys_ioctl fs/ioctl.c:51 [inline]
       __se_sys_ioctl fs/ioctl.c:893 [inline]
       __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893
       __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
       invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
       el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132
       do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
       el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712
       el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730
       el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
    
    The splat is complaining that KVM is advancing PC while an exception is
    pending, i.e. that KVM is retiring the MMIO instruction despite a
    pending synchronous external abort. Womp womp.
    
    Fix the glaring UAPI bug by skipping over all the MMIO emulation in
    case there is a pending synchronous exception. Note that while userspace
    is capable of pending an asynchronous exception (SError, IRQ, or FIQ),
    it is still safe to retire the MMIO instruction in this case as (1) they
    are by definition asynchronous, and (2) KVM relies on hardware support
    for pending/delivering these exceptions instead of the software state
    machine for advancing PC.
    
    Cc: stable@vger.kernel.org
    Fixes: da345174ceca ("KVM: arm/arm64: Allow user injection of external data aborts")
    Reported-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20241025203106.3529261-2-oliver.upton@linux.dev
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b18c92b051abc790181d2820b9bc7efd17bb44c3
Author: Fuad Tabba <tabba@google.com>
Date:   Tue Apr 23 16:05:22 2024 +0100

    KVM: arm64: Change kvm_handle_mmio_return() return polarity
    
    [ Upstream commit cc81b6dfc3bc82c3a2600eefbd3823bdb2190197 ]
    
    Most exit handlers return <= 0 to indicate that the host needs to
    handle the exit. Make kvm_handle_mmio_return() consistent with
    the exit handlers in handle_exit(). This makes the code easier to
    reason about, and makes it easier to add other handlers in future
    patches.
    
    No functional change intended.
    
    Signed-off-by: Fuad Tabba <tabba@google.com>
    Acked-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240423150538.2103045-15-tabba@google.com
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Stable-dep-of: e735a5da6442 ("KVM: arm64: Don't retire aborted MMIO instruction")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1c2c835a0f83a370bb7b5f36f43b9d46127c266
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Tue Dec 3 22:49:20 2024 +0200

    net/mlx5e: Remove workaround to avoid syndrome for internal port
    
    [ Upstream commit 5085f861b414e4a51ce28a891dfa32a10a54b64e ]
    
    Previously a workaround was added to avoid syndrome 0xcdb051. It is
    triggered when offload a rule with tunnel encapsulation, and
    forwarding to another table, but not matching on the internal port in
    firmware steering mode. The original workaround skips internal tunnel
    port logic, which is not correct as not all cases are considered. As
    an example, if vlan is configured on the uplink port, traffic can't
    pass because vlan header is not added with this workaround. Besides,
    there is no such issue for software steering. So, this patch removes
    that, and returns error directly if trying to offload such rule for
    firmware steering.
    
    Fixes: 06b4eac9c4be ("net/mlx5e: Don't offload internal port if filter device is out device")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Tested-by: Frode Nordahl <frode.nordahl@canonical.com>
    Reviewed-by: Chris Mi <cmi@nvidia.com>
    Reviewed-by: Ariel Levkovich <lariel@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/20241203204920.232744-7-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ee7bdc7cb40abfe658a71fbd10c7db2f4fc4f9a
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 3 18:21:21 2024 +0000

    geneve: do not assume mac header is set in geneve_xmit_skb()
    
    [ Upstream commit 8588c99c7d47448fcae39e3227d6e2bb97aad86d ]
    
    We should not assume mac header is set in output path.
    
    Use skb_eth_hdr() instead of eth_hdr() to fix the issue.
    
    sysbot reported the following :
    
     WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]
     WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]
     WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]
     WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039
    Modules linked in:
    CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
     RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]
     RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]
     RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]
     RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039
    Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff
    RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283
    RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000
    RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003
    RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000
    R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23
    FS:  00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
      netdev_start_xmit include/linux/netdevice.h:5011 [inline]
      __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490
      dev_direct_xmit include/linux/netdevice.h:3181 [inline]
      packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285
      packet_snd net/packet/af_packet.c:3146 [inline]
      packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178
      sock_sendmsg_nosec net/socket.c:711 [inline]
      __sock_sendmsg net/socket.c:726 [inline]
      __sys_sendto+0x488/0x4f0 net/socket.c:2197
      __do_sys_sendto net/socket.c:2204 [inline]
      __se_sys_sendto net/socket.c:2200 [inline]
      __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: a025fb5f49ad ("geneve: Allow configuration of DF behaviour")
    Reported-by: syzbot+3ec5271486d7cb2d242a@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/674f4b72.050a0220.17bd51.004a.GAE@google.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Link: https://patch.msgid.link/20241203182122.2725517-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1a68b5702cb09bba79d0624d39bf98c21c00617
Author: Kory Maincent <kory.maincent@bootlin.com>
Date:   Mon Dec 2 16:33:57 2024 +0100

    ethtool: Fix wrong mod state in case of verbose and no_mask bitset
    
    [ Upstream commit 910c4788d6155b2202ec88273376cd7ecdc24f0a ]
    
    A bitset without mask in a _SET request means we want exactly the bits in
    the bitset to be set. This works correctly for compact format but when
    verbose format is parsed, ethnl_update_bitset32_verbose() only sets the
    bits present in the request bitset but does not clear the rest. The commit
    6699170376ab ("ethtool: fix application of verbose no_mask bitset") fixes
    this issue by clearing the whole target bitmap before we start iterating.
    The solution proposed brought an issue with the behavior of the mod
    variable. As the bitset is always cleared the old value will always
    differ to the new value.
    
    Fix it by adding a new function to compare bitmaps and a temporary variable
    which save the state of the old bitmap.
    
    Fixes: 6699170376ab ("ethtool: fix application of verbose no_mask bitset")
    Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
    Link: https://patch.msgid.link/20241202153358.1142095-1-kory.maincent@bootlin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23a6919bb3ecf6787f060476ee6810ad55ebf9c8
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Dec 2 00:04:49 2024 +0100

    netfilter: nft_set_hash: skip duplicated elements pending gc run
    
    [ Upstream commit 7ffc7481153bbabf3332c6a19b289730c7e1edf5 ]
    
    rhashtable does not provide stable walk, duplicated elements are
    possible in case of resizing. I considered that checking for errors when
    calling rhashtable_walk_next() was sufficient to detect the resizing.
    However, rhashtable_walk_next() returns -EAGAIN only at the end of the
    iteration, which is too late, because a gc work containing duplicated
    elements could have been already scheduled for removal to the worker.
    
    Add a u32 gc worker sequence number per set, bump it on every workqueue
    run. Annotate gc worker sequence number on the expired element. Use it
    to skip those already seen in this gc workqueue run.
    
    Note that this new field is never reset in case gc transaction fails, so
    next gc worker run on the expired element overrides it. Wraparound of gc
    worker sequence number should not be an issue with stale gc worker
    sequence number in the element, that would just postpone the element
    removal in one gc run.
    
    Note that it is not possible to use flags to annotate that element is
    pending gc run to detect duplicates, given that gc transaction can be
    invalidated in case of update from the control plane, therefore, not
    allowing to clear such flag.
    
    On x86_64, pahole reports no changes in the size of nft_rhash_elem.
    
    Fixes: f6c383b8c31a ("netfilter: nf_tables: adapt set backend to use GC transaction API")
    Reported-by: Laurent Fasnacht <laurent.fasnacht@proton.ch>
    Tested-by: Laurent Fasnacht <laurent.fasnacht@proton.ch>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bae60a933ba5d16eed55c6b279be51bcbbc79b0
Author: Phil Sutter <phil@nwl.cc>
Date:   Fri Nov 29 16:30:38 2024 +0100

    netfilter: ipset: Hold module reference while requesting a module
    
    [ Upstream commit 456f010bfaefde84d3390c755eedb1b0a5857c3c ]
    
    User space may unload ip_set.ko while it is itself requesting a set type
    backend module, leading to a kernel crash. The race condition may be
    provoked by inserting an mdelay() right after the nfnl_unlock() call.
    
    Fixes: a7b4f989a629 ("netfilter: ipset: IP set core support")
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 082b0dac789a874ea1996e8438c42ce37de13b8b
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Dec 2 10:21:38 2024 -0500

    net: sched: fix erspan_opt settings in cls_flower
    
    [ Upstream commit 292207809486d99c78068d3f459cbbbffde88415 ]
    
    When matching erspan_opt in cls_flower, only the (version, dir, hwid)
    fields are relevant. However, in fl_set_erspan_opt() it initializes
    all bits of erspan_opt and its mask to 1. This inadvertently requires
    packets to match not only the (version, dir, hwid) fields but also the
    other fields that are unexpectedly set to 1.
    
    This patch resolves the issue by ensuring that only the (version, dir,
    hwid) fields are configured in fl_set_erspan_opt(), leaving the other
    fields to 0 in erspan_opt.
    
    Fixes: 79b1011cb33d ("net: sched: allow flower to match erspan options")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8009cdcc493fa30d4572016daf2d6999da4d6c54
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Oct 23 20:10:48 2024 +0800

    igb: Fix potential invalid memory access in igb_init_module()
    
    [ Upstream commit 0566f83d206c7a864abcd741fe39d6e0ae5eef29 ]
    
    The pci_register_driver() can fail and when this happened, the dca_notifier
    needs to be unregistered, otherwise the dca_notifier can be called when
    igb fails to install, resulting to invalid memory access.
    
    Fixes: bbd98fe48a43 ("igb: Fix DCA errors and do not use context index for 82576")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 49b0aa100880de83eaf27c0456ec3a61a995d731
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Nov 1 16:05:43 2024 -0700

    ixgbe: downgrade logging of unsupported VF API version to debug
    
    [ Upstream commit 15915b43a7fb938934bb7fc4290127218859d795 ]
    
    The ixgbe PF driver logs an info message when a VF attempts to negotiate an
    API version which it does not support:
    
      VF 0 requested invalid api version 6
    
    The ixgbevf driver attempts to load with mailbox API v1.5, which is
    required for best compatibility with other hosts such as the ESX VMWare PF.
    
    The Linux PF only supports API v1.4, and does not currently have support
    for the v1.5 API.
    
    The logged message can confuse users, as the v1.5 API is valid, but just
    happens to not currently be supported by the Linux PF.
    
    Downgrade the info message to a debug message, and fix the language to
    use 'unsupported' instead of 'invalid' to improve message clarity.
    
    Long term, we should investigate whether the improvements in the v1.5 API
    make sense for the Linux PF, and if so implement them properly. This may
    require yet another API version to resolve issues with negotiating IPSEC
    offload support.
    
    Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF")
    Reported-by: Yifei Liu <yifei.l.liu@oracle.com>
    Link: https://lore.kernel.org/intel-wired-lan/20240301235837.3741422-1-yifei.l.liu@oracle.com/
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ac227d875bb385e02fecad90a44ed7a51f088fa
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Nov 1 16:05:42 2024 -0700

    ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5
    
    [ Upstream commit d0725312adf5a803de8f621bd1b12ba7a6464a29 ]
    
    Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication
    between PF and VF") added support for v1.5 of the PF to VF mailbox
    communication API. This commit mistakenly enabled IPSEC offload for API
    v1.5.
    
    No implementation of the v1.5 API has support for IPSEC offload. This
    offload is only supported by the Linux PF as mailbox API v1.4. In fact, the
    v1.5 API is not implemented in any Linux PF.
    
    Attempting to enable IPSEC offload on a PF which supports v1.5 API will not
    work. Only the Linux upstream ixgbe and ixgbevf support IPSEC offload, and
    only as part of the v1.4 API.
    
    Fix the ixgbevf Linux driver to stop attempting IPSEC offload when
    the mailbox API does not support it.
    
    The existing API design choice makes it difficult to support future API
    versions, as other non-Linux hosts do not implement IPSEC offload. If we
    add support for v1.5 to the Linux PF, then we lose support for IPSEC
    offload.
    
    A full solution likely requires a new mailbox API with a proper negotiation
    to check that IPSEC is actually supported by the host.
    
    Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6fcf1f335f4198c01bf4564d0186131f4dfa267
Author: Louis Leseur <louis.leseur@gmail.com>
Date:   Thu Nov 28 09:33:58 2024 +0100

    net/qed: allow old cards not supporting "num_images" to work
    
    [ Upstream commit 7a0ea70da56ee8c2716d0b79e9959d3c47efab62 ]
    
    Commit 43645ce03e00 ("qed: Populate nvm image attribute shadow.")
    added support for populating flash image attributes, notably
    "num_images". However, some cards were not able to return this
    information. In such cases, the driver would return EINVAL, causing the
    driver to exit.
    
    Add check to return EOPNOTSUPP instead of EINVAL when the card is not
    able to return these information. The caller function already handles
    EOPNOTSUPP without error.
    
    Fixes: 43645ce03e00 ("qed: Populate nvm image attribute shadow.")
    Co-developed-by: Florian Forestier <florian@forestier.re>
    Signed-off-by: Florian Forestier <florian@forestier.re>
    Signed-off-by: Louis Leseur <louis.leseur@gmail.com>
    Link: https://patch.msgid.link/20241128083633.26431-1-louis.leseur@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cf598548a6c36d90681d53c6b77d52363f2f295
Author: Wen Gu <guwen@linux.alibaba.com>
Date:   Wed Nov 27 21:30:14 2024 +0800

    net/smc: fix LGR and link use-after-free issue
    
    [ Upstream commit 2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7 ]
    
    We encountered a LGR/link use-after-free issue, which manifested as
    the LGR/link refcnt reaching 0 early and entering the clear process,
    making resource access unsafe.
    
     refcount_t: addition on 0; use-after-free.
     WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
     Workqueue: events smc_lgr_terminate_work [smc]
     Call trace:
      refcount_warn_saturate+0x9c/0x140
      __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
      smc_lgr_terminate_work+0x28/0x30 [smc]
      process_one_work+0x1b8/0x420
      worker_thread+0x158/0x510
      kthread+0x114/0x118
    
    or
    
     refcount_t: underflow; use-after-free.
     WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
     Workqueue: smc_hs_wq smc_listen_work [smc]
     Call trace:
      refcount_warn_saturate+0xf0/0x140
      smcr_link_put+0x1cc/0x1d8 [smc]
      smc_conn_free+0x110/0x1b0 [smc]
      smc_conn_abort+0x50/0x60 [smc]
      smc_listen_find_device+0x75c/0x790 [smc]
      smc_listen_work+0x368/0x8a0 [smc]
      process_one_work+0x1b8/0x420
      worker_thread+0x158/0x510
      kthread+0x114/0x118
    
    It is caused by repeated release of LGR/link refcnt. One suspect is that
    smc_conn_free() is called repeatedly because some smc_conn_free() from
    server listening path are not protected by sock lock.
    
    e.g.
    
    Calls under socklock        | smc_listen_work
    -------------------------------------------------------
    lock_sock(sk)               | smc_conn_abort
    smc_conn_free               | \- smc_conn_free
    \- smcr_link_put            |    \- smcr_link_put (duplicated)
    release_sock(sk)
    
    So here add sock lock protection in smc_listen_work() path, making it
    exclusive with other connection operations.
    
    Fixes: 3b2dec2603d5 ("net/smc: restructure client and server code in af_smc")
    Co-developed-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
    Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
    Co-developed-by: Kai <KaiShen@linux.alibaba.com>
    Signed-off-by: Kai <KaiShen@linux.alibaba.com>
    Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d62d5180c036eeac09f80660edc7a602b369125f
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Nov 27 14:05:12 2024 +0900

    tipc: Fix use-after-free of kernel socket in cleanup_bearer().
    
    [ Upstream commit 6a2fa13312e51a621f652d522d7e2df7066330b6 ]
    
    syzkaller reported a use-after-free of UDP kernel socket
    in cleanup_bearer() without repro. [0][1]
    
    When bearer_disable() calls tipc_udp_disable(), cleanup
    of the UDP kernel socket is deferred by work calling
    cleanup_bearer().
    
    tipc_net_stop() waits for such works to finish by checking
    tipc_net(net)->wq_count.  However, the work decrements the
    count too early before releasing the kernel socket,
    unblocking cleanup_net() and resulting in use-after-free.
    
    Let's move the decrement after releasing the socket in
    cleanup_bearer().
    
    [0]:
    ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at
         sk_alloc+0x438/0x608
         inet_create+0x4c8/0xcb0
         __sock_create+0x350/0x6b8
         sock_create_kern+0x58/0x78
         udp_sock_create4+0x68/0x398
         udp_sock_create+0x88/0xc8
         tipc_udp_enable+0x5e8/0x848
         __tipc_nl_bearer_enable+0x84c/0xed8
         tipc_nl_bearer_enable+0x38/0x60
         genl_family_rcv_msg_doit+0x170/0x248
         genl_rcv_msg+0x400/0x5b0
         netlink_rcv_skb+0x1dc/0x398
         genl_rcv+0x44/0x68
         netlink_unicast+0x678/0x8b0
         netlink_sendmsg+0x5e4/0x898
         ____sys_sendmsg+0x500/0x830
    
    [1]:
    BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]
    BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
     udp_hashslot include/net/udp.h:85 [inline]
     udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
     sk_common_release+0xaf/0x3f0 net/core/sock.c:3820
     inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437
     inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489
     __sock_release net/socket.c:658 [inline]
     sock_release+0xa0/0x210 net/socket.c:686
     cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819
     process_one_work kernel/workqueue.c:3229 [inline]
     process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
     worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
     kthread+0x531/0x6b0 kernel/kthread.c:389
     ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
    
    Uninit was created at:
     slab_free_hook mm/slub.c:2269 [inline]
     slab_free mm/slub.c:4580 [inline]
     kmem_cache_free+0x207/0xc40 mm/slub.c:4682
     net_free net/core/net_namespace.c:454 [inline]
     cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647
     process_one_work kernel/workqueue.c:3229 [inline]
     process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
     worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
     kthread+0x531/0x6b0 kernel/kthread.c:389
     ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
    
    CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    Workqueue: events cleanup_bearer
    
    Fixes: 26abe14379f8 ("net: Modify sk_alloc to not reference count the netns of kernel sockets.")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20241127050512.28438-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ff67909ee2ffad911e3122616df41dee23ff4f6
Author: Ivan Solodovnikov <solodovnikov.ia@phystech.edu>
Date:   Tue Nov 26 17:39:02 2024 +0300

    dccp: Fix memory leak in dccp_feat_change_recv
    
    [ Upstream commit 22be4727a8f898442066bcac34f8a1ad0bc72e14 ]
    
    If dccp_feat_push_confirm() fails after new value for SP feature was accepted
    without reconciliation ('entry == NULL' branch), memory allocated for that value
    with dccp_feat_clone_sp_val() is never freed.
    
    Here is the kmemleak stack for this:
    
    unreferenced object 0xffff88801d4ab488 (size 8):
      comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s)
      hex dump (first 8 bytes):
        01 b4 4a 1d 80 88 ff ff                          ..J.....
      backtrace:
        [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128
        [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline]
        [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]
        [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]
        [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]
        [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416
        [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125
        [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650
        [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688
        [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline]
        [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570
        [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111
        [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]
        [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696
        [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735
        [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865
        [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882
        [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline]
        [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline]
        [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889
        [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
        [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
    
    Clean up the allocated memory in case of dccp_feat_push_confirm() failure
    and bail out with an error reset code.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: e77b8363b2ea ("dccp: Process incoming Change feature-negotiation options")
    Signed-off-by: Ivan Solodovnikov <solodovnikov.ia@phystech.edu>
    Link: https://patch.msgid.link/20241126143902.190853-1-solodovnikov.ia@phystech.edu
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 535add1e9f274502209cb997801208bbe1ae6c6f
Author: Jiri Wiesner <jwiesner@suse.de>
Date:   Thu Nov 28 09:59:50 2024 +0100

    net/ipv6: release expired exception dst cached in socket
    
    [ Upstream commit 3301ab7d5aeb0fe270f73a3d4810c9d1b6a9f045 ]
    
    Dst objects get leaked in ip6_negative_advice() when this function is
    executed for an expired IPv6 route located in the exception table. There
    are several conditions that must be fulfilled for the leak to occur:
    * an ICMPv6 packet indicating a change of the MTU for the path is received,
      resulting in an exception dst being created
    * a TCP connection that uses the exception dst for routing packets must
      start timing out so that TCP begins retransmissions
    * after the exception dst expires, the FIB6 garbage collector must not run
      before TCP executes ip6_negative_advice() for the expired exception dst
    
    When TCP executes ip6_negative_advice() for an exception dst that has
    expired and if no other socket holds a reference to the exception dst, the
    refcount of the exception dst is 2, which corresponds to the increment
    made by dst_init() and the increment made by the TCP socket for which the
    connection is timing out. The refcount made by the socket is never
    released. The refcount of the dst is decremented in sk_dst_reset() but
    that decrement is counteracted by a dst_hold() intentionally placed just
    before the sk_dst_reset() in ip6_negative_advice(). After
    ip6_negative_advice() has finished, there is no other object tied to the
    dst. The socket lost its reference stored in sk_dst_cache and the dst is
    no longer in the exception table. The exception dst becomes a leaked
    object.
    
    As a result of this dst leak, an unbalanced refcount is reported for the
    loopback device of a net namespace being destroyed under kernels that do
    not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):
    unregister_netdevice: waiting for lo to become free. Usage count = 2
    
    Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The
    patch that introduced the dst_hold() in ip6_negative_advice() was
    92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22
    merely refactored the code with regards to the dst refcount so the issue
    was present even before 92f1655aa2b22. The bug was introduced in
    54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually
    expired.") where the expired cached route is deleted and the sk_dst_cache
    member of the socket is set to NULL by calling dst_negative_advice() but
    the refcount belonging to the socket is left unbalanced.
    
    The IPv4 version - ipv4_negative_advice() - is not affected by this bug.
    When the TCP connection times out ipv4_negative_advice() merely resets the
    sk_dst_cache of the socket while decrementing the refcount of the
    exception dst.
    
    Fixes: 92f1655aa2b22 ("net: fix __dst_negative_advice() race")
    Fixes: 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.")
    Link: https://lore.kernel.org/netdev/20241113105611.GA6723@incl/T/#u
    Signed-off-by: Jiri Wiesner <jwiesner@suse.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241128085950.GA4505@incl
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3c87e14326ce5963ba4269b6b3e1b5bf8ebb223
Author: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Date:   Tue Feb 13 03:04:28 2024 -0800

    net-timestamp: make sk_tskey more predictable in error path
    
    [ Upstream commit 488b6d91b07112eaaaa4454332c1480894d4e06e ]
    
    When SOF_TIMESTAMPING_OPT_ID is used to ambiguate timestamped datagrams,
    the sk_tskey can become unpredictable in case of any error happened
    during sendmsg(). Move increment later in the code and make decrement of
    sk_tskey in error path. This solution is still racy in case of multiple
    threads doing snedmsg() over the very same socket in parallel, but still
    makes error path much more predictable.
    
    Fixes: 09c2d251b707 ("net-timestamp: add key to disambiguate concurrent datagrams")
    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240213110428.1681540-1-vadfed@meta.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 3301ab7d5aeb ("net/ipv6: release expired exception dst cached in socket")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f117cba69cbbd496babb3defcdf440df4fd6fe14
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Nov 5 12:48:23 2024 +0300

    can: j1939: j1939_session_new(): fix skb reference counting
    
    [ Upstream commit a8c695005bfe6569acd73d777ca298ddddd66105 ]
    
    Since j1939_session_skb_queue() does an extra skb_get() for each new
    skb, do the same for the initial one in j1939_session_new() to avoid
    refcount underflow.
    
    Reported-by: syzbot+d4e8dc385d9258220c31@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d4e8dc385d9258220c31
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://patch.msgid.link/20241105094823.2403806-1-dmantipov@yandex.ru
    [mkl: clean up commit message]
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bb5c8ebc99f0671dbd3c9408ebaf935c3951186
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Nov 26 14:43:44 2024 +0000

    net: hsr: avoid potential out-of-bound access in fill_frame_info()
    
    [ Upstream commit b9653d19e556c6afd035602927a93d100a0d7644 ]
    
    syzbot is able to feed a packet with 14 bytes, pretending
    it is a vlan one.
    
    Since fill_frame_info() is relying on skb->mac_len already,
    extend the check to cover this case.
    
    BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]
     BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
      fill_frame_info net/hsr/hsr_forward.c:709 [inline]
      hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
      hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235
      __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
      netdev_start_xmit include/linux/netdevice.h:5011 [inline]
      xmit_one net/core/dev.c:3590 [inline]
      dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606
      __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434
      dev_queue_xmit include/linux/netdevice.h:3168 [inline]
      packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
      packet_snd net/packet/af_packet.c:3146 [inline]
      packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178
      sock_sendmsg_nosec net/socket.c:711 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:726
      __sys_sendto+0x594/0x750 net/socket.c:2197
      __do_sys_sendto net/socket.c:2204 [inline]
      __se_sys_sendto net/socket.c:2200 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
      x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:4091 [inline]
      slab_alloc_node mm/slub.c:4134 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
      alloc_skb include/linux/skbuff.h:1323 [inline]
      alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612
      sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881
      packet_alloc_skb net/packet/af_packet.c:2995 [inline]
      packet_snd net/packet/af_packet.c:3089 [inline]
      packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178
      sock_sendmsg_nosec net/socket.c:711 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:726
      __sys_sendto+0x594/0x750 net/socket.c:2197
      __do_sys_sendto net/socket.c:2204 [inline]
      __se_sys_sendto net/socket.c:2200 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
      x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 48b491a5cc74 ("net: hsr: fix mac_len checks")
    Reported-by: syzbot+671e2853f9851d039551@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/6745dc7f.050a0220.21d33d.0018.GAE@google.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: WingMan Kwok <w-kwok2@ti.com>
    Cc: Murali Karicheri <m-karicheri2@ti.com>
    Cc: MD Danish Anwar <danishanwar@ti.com>
    Cc: Jiri Pirko <jiri@nvidia.com>
    Cc: George McCollister <george.mccollister@gmail.com>
    Link: https://patch.msgid.link/20241126144344.4177332-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11a9c19c28ba15653d4ed17aa26d16356a582fd9
Author: Martin Ottens <martin.ottens@fau.de>
Date:   Mon Nov 25 18:46:07 2024 +0100

    net/sched: tbf: correct backlog statistic for GSO packets
    
    [ Upstream commit 1596a135e3180c92e42dd1fbcad321f4fb3e3b17 ]
    
    When the length of a GSO packet in the tbf qdisc is larger than the burst
    size configured the packet will be segmented by the tbf_segment function.
    Whenever this function is used to enqueue SKBs, the backlog statistic of
    the tbf is not increased correctly. This can lead to underflows of the
    'backlog' byte-statistic value when these packets are dequeued from tbf.
    
    Reproduce the bug:
    Ensure that the sender machine has GSO enabled. Configured the tbf on
    the outgoing interface of the machine as follows (burstsize = 1 MTU):
    $ tc qdisc add dev <oif> root handle 1: tbf rate 50Mbit burst 1514 latency 50ms
    
    Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
    client on this machine. Check the qdisc statistics:
    $ tc -s qdisc show dev <oif>
    
    The 'backlog' byte-statistic has incorrect values while traffic is
    transferred, e.g., high values due to u32 underflows. When the transfer
    is stopped, the value is != 0, which should never happen.
    
    This patch fixes this bug by updating the statistics correctly, even if
    single SKBs of a GSO SKB cannot be enqueued.
    
    Fixes: e43ac79a4bc6 ("sch_tbf: segment too big GSO packets")
    Signed-off-by: Martin Ottens <martin.ottens@fau.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241125174608.1484356-1-martin.ottens@fau.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 085980b68b035411c1f535ce34d53fbf1091e537
Author: Ajay Kaher <ajay.kaher@broadcom.com>
Date:   Mon Nov 25 10:59:54 2024 +0000

    ptp: Add error handling for adjfine callback in ptp_clock_adjtime
    
    [ Upstream commit 98337d7c87577ded71114f6976edb70a163e27bc ]
    
    ptp_clock_adjtime sets ptp->dialed_frequency even when adjfine
    callback returns an error. This causes subsequent reads to return
    an incorrect value.
    
    Fix this by adding error check before ptp->dialed_frequency is set.
    
    Fixes: 39a8cbd9ca05 ("ptp: remember the adjusted frequency")
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Link: https://patch.msgid.link/20241125105954.1509971-1-ajay.kaher@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4db84fc352d6a2e311fd59841f57e2f667d91942
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Nov 9 15:09:44 2022 -0800

    ptp: convert remaining drivers to adjfine interface
    
    [ Upstream commit e2bd9c76c89fbe25df351fc5902cbbcca6a7d372 ]
    
    Convert all remaining drivers that still use .adjfreq to the newer .adjfine
    implementation. These drivers are not straightforward, as they use
    non-standard methods of programming their hardware. They are all converted
    to use scaled_ppm_to_ppb to get the parts per billion value that their
    logic depends on.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Cc: Ariel Elior <aelior@marvell.com>
    Cc: Sudarsana Kalluru <skalluru@marvell.com>
    Cc: Manish Chopra <manishc@marvell.com>
    Cc: Derek Chickles <dchickles@marvell.com>
    Cc: Satanand Burla <sburla@marvell.com>
    Cc: Felix Manlunas <fmanlunas@marvell.com>
    Cc: Raju Rangoju <rajur@chelsio.com>
    Cc: Joakim Zhang <qiangqing.zhang@nxp.com>
    Cc: Edward Cree <ecree.xilinx@gmail.com>
    Cc: Martin Habets <habetsm.xilinx@gmail.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 98337d7c8757 ("ptp: Add error handling for adjfine callback in ptp_clock_adjtime")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7064a6daa4a700a298fe3aee11dea296bfe59fc4
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Nov 26 11:59:06 2024 +0100

    netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
    
    [ Upstream commit b7529880cb961d515642ce63f9d7570869bbbdc3 ]
    
    cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to
    restrict this maximum depth to a more reasonable value not to harm
    performance. Remove unnecessary WARN_ON_ONCE which is reachable from
    userspace.
    
    Fixes: 7f3287db6543 ("netfilter: nft_socket: make cgroupsv2 matching work with namespaces")
    Reported-by: syzbot+57bac0866ddd99fe47c0@syzkaller.appspotmail.com
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab9916321c95f5280b72b4c5055e269f98627efe
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Thu Nov 21 09:55:42 2024 +0300

    netfilter: x_tables: fix LED ID check in led_tg_check()
    
    [ Upstream commit 04317f4eb2aad312ad85c1a17ad81fe75f1f9bc7 ]
    
    Syzbot has reported the following BUG detected by KASAN:
    
    BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70
    Read of size 1 at addr ffff8881022da0c8 by task repro/5879
    ...
    Call Trace:
     <TASK>
     dump_stack_lvl+0x241/0x360
     ? __pfx_dump_stack_lvl+0x10/0x10
     ? __pfx__printk+0x10/0x10
     ? _printk+0xd5/0x120
     ? __virt_addr_valid+0x183/0x530
     ? __virt_addr_valid+0x183/0x530
     print_report+0x169/0x550
     ? __virt_addr_valid+0x183/0x530
     ? __virt_addr_valid+0x183/0x530
     ? __virt_addr_valid+0x45f/0x530
     ? __phys_addr+0xba/0x170
     ? strlen+0x58/0x70
     kasan_report+0x143/0x180
     ? strlen+0x58/0x70
     strlen+0x58/0x70
     kstrdup+0x20/0x80
     led_tg_check+0x18b/0x3c0
     xt_check_target+0x3bb/0xa40
     ? __pfx_xt_check_target+0x10/0x10
     ? stack_depot_save_flags+0x6e4/0x830
     ? nft_target_init+0x174/0xc30
     nft_target_init+0x82d/0xc30
     ? __pfx_nft_target_init+0x10/0x10
     ? nf_tables_newrule+0x1609/0x2980
     ? nf_tables_newrule+0x1609/0x2980
     ? rcu_is_watching+0x15/0xb0
     ? nf_tables_newrule+0x1609/0x2980
     ? nf_tables_newrule+0x1609/0x2980
     ? __kmalloc_noprof+0x21a/0x400
     nf_tables_newrule+0x1860/0x2980
     ? __pfx_nf_tables_newrule+0x10/0x10
     ? __nla_parse+0x40/0x60
     nfnetlink_rcv+0x14e5/0x2ab0
     ? __pfx_validate_chain+0x10/0x10
     ? __pfx_nfnetlink_rcv+0x10/0x10
     ? __lock_acquire+0x1384/0x2050
     ? netlink_deliver_tap+0x2e/0x1b0
     ? __pfx_lock_release+0x10/0x10
     ? netlink_deliver_tap+0x2e/0x1b0
     netlink_unicast+0x7f8/0x990
     ? __pfx_netlink_unicast+0x10/0x10
     ? __virt_addr_valid+0x183/0x530
     ? __check_object_size+0x48e/0x900
     netlink_sendmsg+0x8e4/0xcb0
     ? __pfx_netlink_sendmsg+0x10/0x10
     ? aa_sock_msg_perm+0x91/0x160
     ? __pfx_netlink_sendmsg+0x10/0x10
     __sock_sendmsg+0x223/0x270
     ____sys_sendmsg+0x52a/0x7e0
     ? __pfx_____sys_sendmsg+0x10/0x10
     __sys_sendmsg+0x292/0x380
     ? __pfx___sys_sendmsg+0x10/0x10
     ? lockdep_hardirqs_on_prepare+0x43d/0x780
     ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
     ? exc_page_fault+0x590/0x8c0
     ? do_syscall_64+0xb6/0x230
     do_syscall_64+0xf3/0x230
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    ...
     </TASK>
    
    Since an invalid (without '\0' byte at all) byte sequence may be passed
    from userspace, add an extra check to ensure that such a sequence is
    rejected as possible ID and so never passed to 'kstrdup()' and further.
    
    Reported-by: syzbot+6c8215822f35fdb35667@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=6c8215822f35fdb35667
    Fixes: 268cb38e1802 ("netfilter: x_tables: add LED trigger target")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 664d0feab92495b6a27edc3d1119e232c0fe8b2b
Author: Jinghao Jia <jinghao7@illinois.edu>
Date:   Sat Nov 23 03:42:56 2024 -0600

    ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
    
    [ Upstream commit 146b6f1112eb30a19776d6c323c994e9d67790db ]
    
    Under certain kernel configurations when building with Clang/LLVM, the
    compiler does not generate a return or jump as the terminator
    instruction for ip_vs_protocol_init(), triggering the following objtool
    warning during build time:
    
      vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()
    
    At runtime, this either causes an oops when trying to load the ipvs
    module or a boot-time panic if ipvs is built-in. This same issue has
    been reported by the Intel kernel test robot previously.
    
    Digging deeper into both LLVM and the kernel code reveals this to be a
    undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer
    of 64 chars to store the registered protocol names and leaves it
    uninitialized after definition. The function calls strnlen() when
    concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE
    strnlen() performs an extra step to check whether the last byte of the
    input char buffer is a null character (commit 3009f891bb9f ("fortify:
    Allow strlen() and strnlen() to pass compile-time known lengths")).
    This, together with possibly other configurations, cause the following
    IR to be generated:
    
      define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 {
        %1 = alloca [64 x i8], align 16
        ...
    
      14:                                               ; preds = %11
        %15 = getelementptr inbounds i8, ptr %1, i64 63
        %16 = load i8, ptr %15, align 1
        %17 = tail call i1 @llvm.is.constant.i8(i8 %16)
        %18 = icmp eq i8 %16, 0
        %19 = select i1 %17, i1 %18, i1 false
        br i1 %19, label %20, label %23
    
      20:                                               ; preds = %14
        %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23
        ...
    
      23:                                               ; preds = %14, %11, %20
        %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24
        ...
      }
    
    The above code calculates the address of the last char in the buffer
    (value %15) and then loads from it (value %16). Because the buffer is
    never initialized, the LLVM GVN pass marks value %16 as undefined:
    
      %13 = getelementptr inbounds i8, ptr %1, i64 63
      br i1 undef, label %14, label %17
    
    This gives later passes (SCCP, in particular) more DCE opportunities by
    propagating the undef value further, and eventually removes everything
    after the load on the uninitialized stack location:
    
      define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 {
        %1 = alloca [64 x i8], align 16
        ...
    
      12:                                               ; preds = %11
        %13 = getelementptr inbounds i8, ptr %1, i64 63
        unreachable
      }
    
    In this way, the generated native code will just fall through to the
    next function, as LLVM does not generate any code for the unreachable IR
    instruction and leaves the function without a terminator.
    
    Zero the on-stack buffer to avoid this possible UB.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202402100205.PWXIz1ZK-lkp@intel.com/
    Co-developed-by: Ruowen Qin <ruqin@redhat.com>
    Signed-off-by: Ruowen Qin <ruqin@redhat.com>
    Signed-off-by: Jinghao Jia <jinghao7@illinois.edu>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6c90ba51e8d70e43ac5bfa9a3ab0e5d3242a749
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:52 2024 +0100

    can: ems_usb: ems_usb_rx_err(): fix {rx,tx}_errors statistics
    
    [ Upstream commit 72a7e2e74b3075959f05e622bae09b115957dffe ]
    
    The ems_usb_rx_err() function only incremented the receive error counter
    and never the transmit error counter, even if the ECC_DIR flag reported
    that an error had occurred during transmission.
    
    Increment the receive/transmit error counter based on the value of the
    ECC_DIR flag.
    
    Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-12-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 425d7c6fa5b201047a9e4546d7bba82a71e542c6
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:51 2024 +0100

    can: sun4i_can: sun4i_can_err(): fix {rx,tx}_errors statistics
    
    [ Upstream commit 595a81988a6fe06eb5849e972c8b9cb21c4e0d54 ]
    
    The sun4i_can_err() function only incremented the receive error counter
    and never the transmit error counter, even if the STA_ERR_DIR flag
    reported that an error had occurred during transmission.
    
    Increment the receive/transmit error counter based on the value of the
    STA_ERR_DIR flag.
    
    Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-11-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94f2bb4386370dc675e31555b42bba647a1031bb
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:50 2024 +0100

    can: sja1000: sja1000_err(): fix {rx,tx}_errors statistics
    
    [ Upstream commit 2c4ef3af4b028a0eaaf378df511d3b425b1df61f ]
    
    The sja1000_err() function only incremented the receive error counter
    and never the transmit error counter, even if the ECC_DIR flag reported
    that an error had occurred during transmission.
    
    Increment the receive/transmit error counter based on the value of the
    ECC_DIR flag.
    
    Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-10-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a76e5e83e90c73ebe49783041c21c6397b6ddee
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:49 2024 +0100

    can: hi311x: hi3110_can_ist(): fix {rx,tx}_errors statistics
    
    [ Upstream commit 3e4645931655776e757f9fb5ae29371cd7cb21a2 ]
    
    The hi3110_can_ist() function was incorrectly incrementing only the
    receive error counter, even in cases of bit or acknowledgment errors that
    occur during transmission.
    
    The fix the issue by incrementing the appropriate counter based on the
    type of error.
    
    Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-9-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3537b2860c63a3a8ed2eca509e510adb8a38f12e
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:48 2024 +0100

    can: ifi_canfd: ifi_canfd_handle_lec_err(): fix {rx,tx}_errors statistics
    
    [ Upstream commit bb03d568bb21b4afe7935d1943bcf68ddea3ea45 ]
    
    The ifi_canfd_handle_lec_err() function was incorrectly incrementing only
    the receive error counter, even in cases of bit or acknowledgment errors
    that occur during transmission.
    
    Fix the issue by incrementing the appropriate counter based on the
    type of error.
    
    Fixes: 5bbd655a8bd0 ("can: ifi: Add more detailed error reporting")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Link: https://patch.msgid.link/20241122221650.633981-8-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0691005ad74d6842319dbbacb454b1368da51ece
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:47 2024 +0100

    can: m_can: m_can_handle_lec_err(): fix {rx,tx}_errors statistics
    
    [ Upstream commit 988d4222bf9039a875a3d48f2fe35c317831ff68 ]
    
    The m_can_handle_lec_err() function was incorrectly incrementing only the
    receive error counter, even in cases of bit or acknowledgment errors that
    occur during transmission.
    
    Fix the issue by incrementing the appropriate counter based on the
    type of error.
    
    Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-7-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ad77eb8f2e07bcfa0e28887d3c7dbb732d92cc1
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:45 2024 +0100

    can: hi311x: hi3110_can_ist(): fix potential use-after-free
    
    [ Upstream commit 9ad86d377ef4a19c75a9c639964879a5b25a433b ]
    
    The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr
    during bus-off") removed the reporting of rxerr and txerr even in case
    of correct operation (i. e. not bus-off).
    
    The error count information added to the CAN frame after netif_rx() is
    a potential use after free, since there is no guarantee that the skb
    is in the same state. It might be freed or reused.
    
    Fix the issue by postponing the netif_rx() call in case of txerr and
    rxerr reporting.
    
    Fixes: a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-5-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a038753993428e7cc9eeb081ca1d5c89be24b0a
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:43 2024 +0100

    can: sun4i_can: sun4i_can_err(): call can_change_state() even if cf is NULL
    
    [ Upstream commit ee6bf3677ae03569d833795064e17f605c2163c7 ]
    
    Call the function can_change_state() if the allocation of the skb
    fails, as it handles the cf parameter when it is null.
    
    Additionally, this ensures that the statistics related to state error
    counters (i. e. warning, passive, and bus-off) are updated.
    
    Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-3-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5435a6d5c1f22fe2f59abe92d92ad7af68317ab
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 22 23:15:42 2024 +0100

    can: c_can: c_can_handle_bus_err(): update statistics if skb allocation fails
    
    [ Upstream commit 9e66242504f49e17481d8e197730faba7d99c934 ]
    
    Ensure that the statistics are always updated, even if the skb
    allocation fails.
    
    Fixes: 4d6d26537940 ("can: c_can: fix {rx,tx}_errors statistics")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://patch.msgid.link/20241122221650.633981-2-dario.binacchi@amarulasolutions.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6109556cacbbfc8f1871a7999007ce408f927a3
Author: Alexander Kozhinov <ak.alexander.kozhinov@gmail.com>
Date:   Fri Oct 18 23:24:26 2024 +0200

    can: gs_usb: add usb endpoint address detection at driver probe step
    
    [ Upstream commit 889b2ae9139a87b3390f7003cb1bb3d65bf90a26 ]
    
    There is an approach made to implement gs_usb firmware/driver based on
    Zephyr RTOS. It was found that USB stack of Zephyr RTOS overwrites USB
    EP addresses, if they have different last 4 bytes in absence of other
    endpoints.
    
    For example in case of gs_usb candlelight firmware EP-IN is 0x81 and
    EP-OUT 0x02. If there are no additional USB endpoints, Zephyr RTOS will
    overwrite EP-OUT to 0x01. More information can be found in the
    discussion with Zephyr RTOS USB stack maintainer here:
    
    https://github.com/zephyrproject-rtos/zephyr/issues/67812
    
    There are already two different gs_usb FW driver implementations based
    on Zephyr RTOS:
    
    1. https://github.com/CANnectivity/cannectivity
       (by: https://github.com/henrikbrixandersen)
    2. https://github.com/zephyrproject-rtos/zephyr/compare/main...KozhinovAlexander:zephyr:gs_usb
       (by: https://github.com/KozhinovAlexander)
    
    At the moment both Zephyr RTOS implementations use dummy USB endpoint,
    to overcome described USB stack behavior from Zephyr itself. Since
    Zephyr RTOS is intended to be used on microcontrollers with very
    constrained amount of resources (ROM, RAM) and additional endpoint
    requires memory, it is more convenient to update the gs_usb driver in
    the Linux kernel.
    
    To fix this problem, update the gs_usb driver from using hard coded
    endpoint numbers to evaluate the endpoint descriptors and use the
    endpoints provided there.
    
    Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
    Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Alexander Kozhinov <ak.alexander.kozhinov@gmail.com>
    Link: https://patch.msgid.link/20241018212450.31746-1-ak.alexander.kozhinov@gmail.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 003f492e95e2bd5022b18531330a3feb3989b1bf
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Tue Jun 25 16:03:52 2024 +0200

    can: gs_usb: add VID/PID for Xylanta SAINT3 product family
    
    [ Upstream commit 69e2326a21ef409d6c709cb990565331727b9f27 ]
    
    Add support for the Xylanta SAINT3 product family.
    
    Cc: Andy Jackson <andy@xylanta.com>
    Cc: Ken Aitchison <ken@xylanta.com>
    Tested-by: Andy Jackson <andy@xylanta.com>
    Link: https://lore.kernel.org/all/20240625140353.769373-1-mkl@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 889b2ae9139a ("can: gs_usb: add usb endpoint address detection at driver probe step")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92cd695dd57a3656fdb2df51027547a4401657d4
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Jul 6 16:16:33 2023 +0200

    can: gs_usb: uniformly use "parent" as variable name for struct gs_usb
    
    [ Upstream commit b6980ad3a90c73c95cab97e9a33129b8f53e2a5b ]
    
    To ease readability and maintainability uniformly use the variable
    name "parent" for the struct gs_usb in the gs_usb driver.
    
    Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-4-c3b9154ec605@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 889b2ae9139a ("can: gs_usb: add usb endpoint address detection at driver probe step")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a04d8f583474fca26eaa5b3542229d2c714eb8a3
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Jul 6 13:08:43 2023 +0200

    can: gs_usb: gs_usb_probe(): align block comment
    
    [ Upstream commit 5780148bedd6aa7e51d3a18cd70f5b9b6cefb79e ]
    
    Indent block comment so that it aligns the * on each line.
    
    Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-2-c3b9154ec605@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 889b2ae9139a ("can: gs_usb: add usb endpoint address detection at driver probe step")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c5d3466681f717e9018f0980416a15da8ac424c
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Tue Jul 18 11:11:22 2023 +0200

    can: gs_usb: remove leading space from goto labels
    
    [ Upstream commit f1a14714bf48f87fa8e774f415ea9815daf3750d ]
    
    Remove leading spaces from goto labels in accordance with the kernel
    encoding style.
    
    Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-1-c3b9154ec605@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 889b2ae9139a ("can: gs_usb: add usb endpoint address detection at driver probe step")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e58e41c25a9ff3681de53bd3fff7d94136ba4dc9
Author: Yassine Oudjana <y.oudjana@protonmail.com>
Date:   Wed Nov 6 10:47:51 2024 +0000

    watchdog: mediatek: Make sure system reset gets asserted in mtk_wdt_restart()
    
    [ Upstream commit a1495a21e0b8aad92132dfcf9c6fffc1bde9d5b2 ]
    
    Clear the IRQ enable bit of WDT_MODE before asserting software reset
    in order to make TOPRGU issue a system reset signal instead of an IRQ.
    
    Fixes: a44a45536f7b ("watchdog: Add driver for Mediatek watchdog")
    Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20241106104738.195968-2-y.oudjana@protonmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0c1a72b56742c65e3a420ed60e0d66b35946f5c
Author: Nick Chan <towinchenmi@gmail.com>
Date:   Wed Oct 2 00:59:51 2024 +0800

    watchdog: apple: Actually flush writes after requesting watchdog restart
    
    [ Upstream commit 51dfe714c03c066aabc815a2bb2adcc998dfcb30 ]
    
    Although there is an existing code comment about flushing the writes,
    writes were not actually being flushed.
    
    Actually flush the writes by changing readl_relaxed() to readl().
    
    Fixes: 4ed224aeaf661 ("watchdog: Add Apple SoC watchdog driver")
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Nick Chan <towinchenmi@gmail.com>
    Reviewed-by: Guenter Roeck  <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20241001170018.20139-2-towinchenmi@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bcea01215478d139d0b43b2e3d9e3da0e9a21f4
Author: Oleksandr Ocheretnyi <oocheret@cisco.com>
Date:   Fri Sep 13 12:14:03 2024 -0700

    iTCO_wdt: mask NMI_NOW bit for update_no_reboot_bit() call
    
    [ Upstream commit daa814d784ac034c62ab3fb0ef83daeafef527e2 ]
    
    Commit da23b6faa8bf ("watchdog: iTCO: Add support for Cannon Lake
    PCH iTCO") does not mask NMI_NOW bit during TCO1_CNT register's
    value comparison for update_no_reboot_bit() call causing following
    failure:
    
       ...
       iTCO_vendor_support: vendor-support=0
       iTCO_wdt iTCO_wdt: unable to reset NO_REBOOT flag, device
                                        disabled by hardware/BIOS
       ...
    
    and this can lead to unexpected NMIs later during regular
    crashkernel's workflow because of watchdog probe call failures.
    
    This change masks NMI_NOW bit for TCO1_CNT register values to
    avoid unexpected NMI_NOW bit inversions.
    
    Fixes: da23b6faa8bf ("watchdog: iTCO: Add support for Cannon Lake PCH iTCO")
    Signed-off-by: Oleksandr Ocheretnyi <oocheret@cisco.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: https://lore.kernel.org/r/20240913191403.2560805-1-oocheret@cisco.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d17b991ac4d5bb31bad49954982f9270a0d1ff9b
Author: Umio Yasuno <coelacanth_dream@protonmail.com>
Date:   Thu Nov 14 16:15:27 2024 +0900

    drm/amd/pm: update current_socclk and current_uclk in gpu_metrics on smu v13.0.7
    
    commit 2abf2f7032df4c4e7f6cf7906da59d0e614897d6 upstream.
    
    These were missed before.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3751
    Signed-off-by: Umio Yasuno <coelacanth_dream@protonmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42c2dab66284d67cf41afd6543a22b3fc8982801
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Oct 25 17:14:46 2024 +0200

    drm/etnaviv: flush shader L1 cache after user commandstream
    
    commit 4f8dbadef085ab447a01a8d4806a3f629fea05ed upstream.
    
    The shader L1 cache is a writeback cache for shader loads/stores
    and thus must be flushed before any BOs backing the shader buffers
    are potentially freed.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40725c5fabee804fecce41d4d5c5bae80c45e1c4
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Fri Sep 13 17:04:12 2024 +0800

    drm/sti: avoid potential dereference of error pointers
    
    commit 831214f77037de02afc287eae93ce97f218d8c04 upstream.
    
    The return value of drm_atomic_get_crtc_state() needs to be
    checked. To avoid use of error pointer 'crtc_state' in case
    of the failure.
    
    Cc: stable@vger.kernel.org
    Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240913090412.2022848-1-make24@iscas.ac.cn
    Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b79612ed6bc1a184c45427105c851b5b2d4342ca
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Mon Sep 9 14:33:59 2024 +0800

    drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check
    
    commit e965e771b069421c233d674c3c8cd8c7f7245f42 upstream.
    
    The return value of drm_atomic_get_crtc_state() needs to be
    checked. To avoid use of error pointer 'crtc_state' in case
    of the failure.
    
    Cc: stable@vger.kernel.org
    Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Acked-by: Alain Volmat <alain.volmat@foss.st.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240909063359.1197065-1-make24@iscas.ac.cn
    Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b0d0d6e9d3c26697230bf7dc9e6b52bdb24086f
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Fri Sep 13 17:09:26 2024 +0800

    drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check
    
    commit c1ab40a1fdfee732c7e6ff2fb8253760293e47e8 upstream.
    
    The return value of drm_atomic_get_crtc_state() needs to be
    checked. To avoid use of error pointer 'crtc_state' in case
    of the failure.
    
    Cc: stable@vger.kernel.org
    Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240913090926.2023716-1-make24@iscas.ac.cn
    Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44a2c518ab221c0cadcb8c45ca86f83a52dd4da6
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue May 7 14:12:10 2024 -0400

    btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()
    
    commit a580fb2c3479d993556e1c31b237c9e5be4944a3 upstream.
    
    We handle errors here properly, ENOMEM isn't fatal, return the error.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Keerthana K <keerthana.kalyanasundaram@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 005873743f1b2aa6bd9da58e91f1d7fc7da9edf8
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Oct 9 12:26:09 2024 -0700

    powerpc: Adjust adding stack protector flags to KBUILD_CLAGS for clang
    
    commit bee08a9e6ab03caf14481d97b35a258400ffab8f upstream.
    
    After fixing the HAVE_STACKPROTECTER checks for clang's in-progress
    per-task stack protector support [1], the build fails during prepare0
    because '-mstack-protector-guard-offset' has not been added to
    KBUILD_CFLAGS yet but the other '-mstack-protector-guard' flags have.
    
      clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default
      clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default
      make[4]: *** [scripts/Makefile.build:229: scripts/mod/empty.o] Error 1
      make[4]: *** [scripts/Makefile.build:102: scripts/mod/devicetable-offsets.s] Error 1
    
    Mirror other architectures and add all '-mstack-protector-guard' flags
    to KBUILD_CFLAGS atomically during stack_protector_prepare, which
    resolves the issue and allows clang's implementation to fully work with
    the kernel.
    
    Cc: stable@vger.kernel.org # 6.1+
    Link: https://github.com/llvm/llvm-project/pull/110928 [1]
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Tested-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-2-12fb86b31857@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d497cdd2c3ba1d75938194b2da1c48da1aed88fa
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Oct 9 12:26:08 2024 -0700

    powerpc: Fix stack protector Kconfig test for clang
    
    commit 46e1879deea22eed31e9425d58635895fc0e8040 upstream.
    
    Clang's in-progress per-task stack protector support [1] does not work
    with the current Kconfig checks because '-mstack-protector-guard-offset'
    is not provided, unlike all other architecture Kconfig checks.
    
      $ fd Kconfig -x rg -l mstack-protector-guard-offset
      ./arch/arm/Kconfig
      ./arch/riscv/Kconfig
      ./arch/arm64/Kconfig
    
    This produces an error from clang, which is interpreted as the flags not
    being supported at all when they really are.
    
      $ clang --target=powerpc64-linux-gnu \
              -mstack-protector-guard=tls \
              -mstack-protector-guard-reg=r13 \
              -c -o /dev/null -x c /dev/null
      clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default
    
    This argument will always be provided by the build system, so mirror
    other architectures and use '-mstack-protector-guard-offset=0' for
    testing support, which fixes the issue for clang and does not regress
    support with GCC.
    
    Even with the first problem addressed, the 32-bit test continues to fail
    because Kbuild uses the powerpc64le-linux-gnu target for clang and
    nothing flips the target to 32-bit, resulting in an error about an
    invalid register valid:
    
      $ clang --target=powerpc64le-linux-gnu \
              -mstack-protector-guard=tls
              -mstack-protector-guard-reg=r2 \
              -mstack-protector-guard-offset=0 \
              -x c -c -o /dev/null /dev/null
      clang: error: invalid value 'r2' in 'mstack-protector-guard-reg=', expected one of: r13
    
    While GCC allows arbitrary registers, the implementation of
    '-mstack-protector-guard=tls' in LLVM shares the same code path as the
    user space thread local storage implementation, which uses a fixed
    register (2 for 32-bit and 13 for 62-bit), so the command line parsing
    enforces this limitation.
    
    Use the Kconfig macro '$(m32-flag)', which expands to '-m32' when
    supported, in the stack protector support cc-option call to properly
    switch the target to a 32-bit one, which matches what happens in Kbuild.
    While the 64-bit macro does not strictly need it, add the equivalent
    64-bit option for symmetry.
    
    Cc: stable@vger.kernel.org # 6.1+
    Link: https://github.com/llvm/llvm-project/pull/110928 [1]
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Tested-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-1-12fb86b31857@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00663d3e000c31d0d49ef86a809f5c107c2d09cd
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Tue Oct 29 13:46:37 2024 +0000

    iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer
    
    commit 3a4187ec454e19903fd15f6e1825a4b84e59a4cd upstream.
    
    The AD7923 was updated to support devices with 8 channels, but the size
    of tx_buf and ring_xfer was not increased accordingly, leading to a
    potential buffer overflow in ad7923_update_scan_mode().
    
    Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Signed-off-by: Zicheng Qu <quzicheng@huawei.com>
    Link: https://patch.msgid.link/20241029134637.2261336-1-quzicheng@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa4c8ae526d6188dc2c7189dffbe1575fd744f20
Author: Zicheng Qu <quzicheng@huawei.com>
Date:   Sat Nov 2 09:25:25 2024 +0000

    iio: Fix fwnode_handle in __fwnode_iio_channel_get_by_name()
    
    commit 3993ca4add248f0f853f54f9273a7de850639f33 upstream.
    
    In the fwnode_iio_channel_get_by_name(), iterating over parent nodes to
    acquire IIO channels via fwnode_for_each_parent_node(). The variable
    chan was mistakenly attempted on the original node instead of the
    current parent node. This patch corrects the logic to ensure that
    __fwnode_iio_channel_get_by_name() is called with the correct parent
    node.
    
    Cc: stable@vger.kernel.org # v6.6+
    Fixes: 1e64b9c5f9a0 ("iio: inkern: move to fwnode properties")
    Signed-off-by: Zicheng Qu <quzicheng@huawei.com>
    Link: https://patch.msgid.link/20241102092525.2389952-1-quzicheng@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45abb68c941ebc9a35c6d3a7b08196712093c636
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Tue Nov 5 19:03:14 2024 +0800

    nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
    
    commit 98100e88dd8865999dc6379a3356cd799795fe7b upstream.
    
    The action force umount(umount -f) will attempt to kill all rpc_task even
    umount operation may ultimately fail if some files remain open.
    Consequently, if an action attempts to open a file, it can potentially
    send two rpc_task to nfs server.
    
                       NFS CLIENT
    thread1                             thread2
    open("file")
    ...
    nfs4_do_open
     _nfs4_do_open
      _nfs4_open_and_get_state
       _nfs4_proc_open
        nfs4_run_open_task
         /* rpc_task1 */
         rpc_run_task
         rpc_wait_for_completion_task
    
                                        umount -f
                                        nfs_umount_begin
                                         rpc_killall_tasks
                                          rpc_signal_task
         rpc_task1 been wakeup
         and return -512
     _nfs4_do_open // while loop
        ...
        nfs4_run_open_task
         /* rpc_task2 */
         rpc_run_task
         rpc_wait_for_completion_task
    
    While processing an open request, nfsd will first attempt to find or
    allocate an nfs4_openowner. If it finds an nfs4_openowner that is not
    marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since
    two rpc_task can attempt to open the same file simultaneously from the
    client to server, and because two instances of nfsd can run
    concurrently, this situation can lead to lots of memory leak.
    Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be
    triggered.
    
                        NFS SERVER
    nfsd1                  nfsd2       echo 0 > /proc/fs/nfsd/threads
    
    nfsd4_open
     nfsd4_process_open1
      find_or_alloc_open_stateowner
       // alloc oo1, stateid1
                           nfsd4_open
                            nfsd4_process_open1
                            find_or_alloc_open_stateowner
                            // find oo1, without NFS4_OO_CONFIRMED
                             release_openowner
                              unhash_openowner_locked
                              list_del_init(&oo->oo_perclient)
                              // cannot find this oo
                              // from client, LEAK!!!
                             alloc_stateowner // alloc oo2
    
     nfsd4_process_open2
      init_open_stateid
      // associate oo1
      // with stateid1, stateid1 LEAK!!!
      nfs4_get_vfs_file
      // alloc nfsd_file1 and nfsd_file_mark1
      // all LEAK!!!
    
                             nfsd4_process_open2
                             ...
    
                                        write_threads
                                         ...
                                         nfsd_destroy_serv
                                          nfsd_shutdown_net
                                           nfs4_state_shutdown_net
                                            nfs4_state_destroy_net
                                             destroy_client
                                              __destroy_client
                                              // won't find oo1!!!
                                         nfsd_shutdown_generic
                                          nfsd_file_cache_shutdown
                                           kmem_cache_destroy
                                           for nfsd_file_slab
                                           and nfsd_file_mark_slab
                                           // bark since nfsd_file1
                                           // and nfsd_file_mark1
                                           // still alive
    
    =======================================================================
    BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
    __kmem_cache_shutdown()
    -----------------------------------------------------------------------
    
    Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28
    flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
    CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.16.1-2.fc37 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x53/0x70
     slab_err+0xb0/0xf0
     __kmem_cache_shutdown+0x15c/0x310
     kmem_cache_destroy+0x66/0x160
     nfsd_file_cache_shutdown+0xac/0x210 [nfsd]
     nfsd_destroy_serv+0x251/0x2a0 [nfsd]
     nfsd_svc+0x125/0x1e0 [nfsd]
     write_threads+0x16a/0x2a0 [nfsd]
     nfsctl_transaction_write+0x74/0xa0 [nfsd]
     vfs_write+0x1ae/0x6d0
     ksys_write+0xc1/0x160
     do_syscall_64+0x5f/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Disabling lock debugging due to kernel taint
    Object 0xff11000110e2ac38 @offset=3128
    Allocated in nfsd_file_do_acquire+0x20f/0xa30 [nfsd] age=1635 cpu=3
    pid=800
     nfsd_file_do_acquire+0x20f/0xa30 [nfsd]
     nfsd_file_acquire_opened+0x5f/0x90 [nfsd]
     nfs4_get_vfs_file+0x4c9/0x570 [nfsd]
     nfsd4_process_open2+0x713/0x1070 [nfsd]
     nfsd4_open+0x74b/0x8b0 [nfsd]
     nfsd4_proc_compound+0x70b/0xc20 [nfsd]
     nfsd_dispatch+0x1b4/0x3a0 [nfsd]
     svc_process_common+0x5b8/0xc50 [sunrpc]
     svc_process+0x2ab/0x3b0 [sunrpc]
     svc_handle_xprt+0x681/0xa20 [sunrpc]
     nfsd+0x183/0x220 [nfsd]
     kthread+0x199/0x1e0
     ret_from_fork+0x31/0x60
     ret_from_fork_asm+0x1a/0x30
    
    Add nfs4_openowner_unhashed to help found unhashed nfs4_openowner, and
    break nfsd4_open process to fix this problem.
    
    Cc: stable@vger.kernel.org # v5.4+
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d8f7816bebcd2e7400bb4d786eccb8f33c9f9ec
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Mon Oct 21 22:23:41 2024 +0800

    nfsd: make sure exp active before svc_export_show
    
    commit be8f982c369c965faffa198b46060f8853e0f1f0 upstream.
    
    The function `e_show` was called with protection from RCU. This only
    ensures that `exp` will not be freed. Therefore, the reference count for
    `exp` can drop to zero, which will trigger a refcount use-after-free
    warning when `exp_get` is called. To resolve this issue, use
    `cache_get_rcu` to ensure that `exp` remains active.
    
    ------------[ cut here ]------------
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 3 PID: 819 at lib/refcount.c:25
    refcount_warn_saturate+0xb1/0x120
    CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.16.1-2.fc37 04/01/2014
    RIP: 0010:refcount_warn_saturate+0xb1/0x120
    ...
    Call Trace:
     <TASK>
     e_show+0x20b/0x230 [nfsd]
     seq_read_iter+0x589/0x770
     seq_read+0x1e5/0x270
     vfs_read+0x125/0x530
     ksys_read+0xc1/0x160
     do_syscall_64+0x5f/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fixes: bf18f163e89c ("NFSD: Using exp_get for export getting")
    Cc: stable@vger.kernel.org # 4.20+
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39353c92599792be39916494e9df5e47703f57a0
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Oct 17 10:58:36 2024 +0900

    PCI: rockchip-ep: Fix address translation unit programming
    
    commit 64f093c4d99d797b68b407a9d8767aadc3e3ea7a upstream.
    
    The Rockchip PCIe endpoint controller handles PCIe transfers addresses
    by masking the lower bits of the programmed PCI address and using the
    same number of lower bits masked from the CPU address space used for the
    mapping. For a PCI mapping of <size> bytes starting from <pci_addr>,
    the number of bits masked is the number of address bits changing in the
    address range [pci_addr..pci_addr + size - 1].
    
    However, rockchip_pcie_prog_ep_ob_atu() calculates num_pass_bits only
    using the size of the mapping, resulting in an incorrect number of mask
    bits depending on the value of the PCI address to map.
    
    Fix this by introducing the helper function
    rockchip_pcie_ep_ob_atu_num_bits() to correctly calculate the number of
    mask bits to use to program the address translation unit. The number of
    mask bits is calculated depending on both the PCI address and size of
    the mapping, and clamped between 8 and 20 using the macros
    ROCKCHIP_PCIE_AT_MIN_NUM_BITS and ROCKCHIP_PCIE_AT_MAX_NUM_BITS. As
    defined in the Rockchip RK3399 TRM V1.3 Part2, Sections 17.5.5.1.1 and
    17.6.8.2.1, this clamping is necessary because:
    
      1) The lower 8 bits of the PCI address to be mapped by the outbound
         region are ignored. So a minimum of 8 address bits are needed and
         imply that the PCI address must be aligned to 256.
    
      2) The outbound memory regions are 1MB in size. So while we can specify
         up to 63-bits for the PCI address (num_bits filed uses bits 0 to 5 of
         the outbound address region 0 register), we must limit the number of
         valid address bits to 20 to match the memory window maximum size (1
         << 20 = 1MB).
    
    Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
    Link: https://lore.kernel.org/r/20241017015849.190271-2-dlemoal@kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6404f3ae4ffc065d4028900e8bd0dde9eb94f88c
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Nov 6 09:03:12 2024 +0800

    dm thin: Add missing destroy_work_on_stack()
    
    commit e74fa2447bf9ed03d085b6d91f0256cc1b53f1a8 upstream.
    
    This commit add missed destroy_work_on_stack() operations for pw->worker in
    pool_work_wait().
    
    Fixes: e7a3e871d895 ("dm thin: cleanup noflush_work to use a proper completion")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 514b6cca204c8c209d8916aa81cd59ff5f91a2b2
Author: Oleksandr Tymoshenko <ovt@google.com>
Date:   Wed Oct 30 00:28:55 2024 +0000

    ovl: properly handle large files in ovl_security_fileattr
    
    commit 3b6b99ef15ea37635604992ede9ebcccef38a239 upstream.
    
    dentry_open in ovl_security_fileattr fails for any file
    larger than 2GB if open method of the underlying filesystem
    calls generic_file_open (e.g. fusefs).
    
    The issue can be reproduce using the following script:
    (passthrough_ll is an example app from libfuse).
    
      $ D=/opt/test/mnt
      $ mkdir -p ${D}/{source,base,top/uppr,top/work,ovlfs}
      $ dd if=/dev/zero of=${D}/source/zero.bin bs=1G count=2
      $ passthrough_ll -o source=${D}/source ${D}/base
      $ mount -t overlay overlay \
          -olowerdir=${D}/base,upperdir=${D}/top/uppr,workdir=${D}/top/work \
          ${D}/ovlfs
      $ chmod 0777 ${D}/mnt/ovlfs/zero.bin
    
    Running this script results in "Value too large for defined data type"
    error message from chmod.
    
    Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
    Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags")
    Cc: stable@vger.kernel.org # v5.15+
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 748d495e87b344e0d91fc5de6ecb707fb8dc9adb
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Thu Nov 14 12:02:13 2024 -0800

    thermal: int3400: Fix reading of current_uuid for active policy
    
    commit 7082503622986537f57bdb5ef23e69e70cfad881 upstream.
    
    When the current_uuid attribute is set to the active policy UUID,
    reading back the same attribute is returning "INVALID" instead of
    the active policy UUID on some platforms before Ice Lake.
    
    In platforms before Ice Lake, firmware provides a list of supported
    thermal policies. In this case, user space can select any of the
    supported thermal policies via a write to attribute "current_uuid".
    
    In commit c7ff29763989 ("thermal: int340x: Update OS policy capability
    handshake")', the OS policy handshake was updated to support Ice Lake
    and later platforms and it treated priv->current_uuid_index=0 as
    invalid. However, priv->current_uuid_index=0 is for the active policy,
    only priv->current_uuid_index=-1 is invalid.
    
    Fix this issue by updating the priv->current_uuid_index check.
    
    Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake")
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: 5.18+ <stable@vger.kernel.org> # 5.18+
    Link: https://patch.msgid.link/20241114200213.422303-1-srinivas.pandruvada@linux.intel.com
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8ceff49954f857007439d18fca06e531125a191
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Fri Nov 22 00:11:18 2024 +0100

    fs/proc/kcore.c: Clear ret value in read_kcore_iter after successful iov_iter_zero
    
    commit 088f294609d8f8816dc316681aef2eb61982e0da upstream.
    
    If iov_iter_zero succeeds after failed copy_from_kernel_nofault,
    we need to reset the ret value to zero otherwise it will be returned
    as final return value of read_kcore_iter.
    
    This fixes objdump -d dump over /proc/kcore for me.
    
    Cc: stable@vger.kernel.org
    Cc: Alexander Gordeev <agordeev@linux.ibm.com>
    Fixes: 3d5854d75e31 ("fs/proc/kcore.c: allow translation of physical memory addresses")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20241121231118.3212000-1-jolsa@kernel.org
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0c2cb03ab621e0a4d0a007723737c8ea2298d76
Author: Kishon Vijay Abraham I <kishon@kernel.org>
Date:   Fri May 24 16:27:14 2024 +0530

    PCI: keystone: Add link up check to ks_pcie_other_map_bus()
    
    commit 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b upstream.
    
    K2G forwards the error triggered by a link-down state (e.g., no connected
    endpoint device) on the system bus for PCI configuration transactions;
    these errors are reported as an SError at system level, which is fatal and
    hangs the system.
    
    So, apply fix similar to how it was done in the DesignWare Core driver
    commit 15b23906347c ("PCI: dwc: Add link up check in dw_child_pcie_ops.map_bus()").
    
    Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors")
    Link: https://lore.kernel.org/r/20240524105714.191642-3-s-vadapalli@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    [kwilczynski: commit log, added tag for stable releases]
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 481a1e8a790c2771ca83cf8522513b0f3cfa04ac
Author: Kishon Vijay Abraham I <kishon@kernel.org>
Date:   Fri May 24 16:27:13 2024 +0530

    PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible
    
    commit 5a938ed9481b0c06cb97aec45e722a80568256fd upstream.
    
    commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x
    Platforms") introduced configuring "enum dw_pcie_device_mode" as part of
    device data ("struct ks_pcie_of_data"). However it failed to set the
    mode for "ti,keystone-pcie" compatible.
    
    Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error
    message is displayed for the v3.65a controller:
    
      "INVALID device type 0"
    
    Despite the driver probing successfully, the controller may not be
    functional in the Root Complex mode of operation.
    
    So, set the mode as Root Complex for "ti,keystone-pcie" compatible to
    fix this.
    
    Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms")
    Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    [kwilczynski: commit log, added tag for stable releases]
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 991e33a99fd3b5d432f0629565f532f563fe019a
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Oct 1 12:26:08 2024 -0400

    i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()
    
    commit 3082990592f7c6d7510a9133afa46e31bbe26533 upstream.
    
    if (dev->boardinfo && dev->boardinfo->init_dyn_addr)
                                          ^^^ here check "init_dyn_addr"
            i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...)
                                                                 ^^^^
                                                            free "dyn_addr"
    Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".
    
    Cc: stable@kernel.org
    Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1cf8c117717d13f5ad002f15824dbccd0ba60f8
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Sep 30 17:19:13 2024 +0800

    i3c: master: svc: Fix pm_runtime_set_suspended() with runtime pm enabled
    
    commit 18599e93e4e814ce146186026c6abf83c14d5798 upstream.
    
    It is not valid to call pm_runtime_set_suspended() for devices
    with runtime PM enabled because it returns -EAGAIN if it is enabled
    already and working. So, call pm_runtime_disable() before to fix it.
    
    Cc: stable@vger.kernel.org # v5.17
    Fixes: 05be23ef78f7 ("i3c: master: svc: add runtime pm support")
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20240930091913.2545510-1-ruanjinjie@huawei.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6968bcb7fa6a532b849e0f2a598032e45ad4d59d
Author: Peter Griffin <peter.griffin@linaro.org>
Date:   Thu Oct 31 15:00:31 2024 +0000

    scsi: ufs: exynos: Fix hibern8 notify callbacks
    
    commit ceef938bbf8b93ba3a218b4adc244cde94b582aa upstream.
    
    v1 of the patch which introduced the ufshcd_vops_hibern8_notify()
    callback used a bool instead of an enum. In v2 this was updated to an
    enum based on the review feedback in [1].
    
    ufs-exynos hibernate calls have always been broken upstream as it
    follows the v1 bool implementation.
    
    Link: https://patchwork.kernel.org/project/linux-scsi/patch/001f01d23994$719997c0$54ccc740$@samsung.com/ [1]
    Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs")
    Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
    Link: https://lore.kernel.org/r/20241031150033.3440894-13-peter.griffin@linaro.org
    Cc: stable@vger.kernel.org
    Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a87760ae394cbe2e111fa01b935153e160ea1d6b
Author: Alexandru Ardelean <aardelean@baylibre.com>
Date:   Tue Nov 5 16:54:05 2024 +0200

    util_macros.h: fix/rework find_closest() macros
    
    commit bc73b4186736341ab5cd2c199da82db6e1134e13 upstream.
    
    A bug was found in the find_closest() (find_closest_descending() is also
    affected after some testing), where for certain values with small
    progressions, the rounding (done by averaging 2 values) causes an
    incorrect index to be returned.  The rounding issues occur for
    progressions of 1, 2 and 3.  It goes away when the progression/interval
    between two values is 4 or larger.
    
    It's particularly bad for progressions of 1.  For example if there's an
    array of 'a = { 1, 2, 3 }', using 'find_closest(2, a ...)' would return 0
    (the index of '1'), rather than returning 1 (the index of '2').  This
    means that for exact values (with a progression of 1), find_closest() will
    misbehave and return the index of the value smaller than the one we're
    searching for.
    
    For progressions of 2 and 3, the exact values are obtained correctly; but
    values aren't approximated correctly (as one would expect).  Starting with
    progressions of 4, all seems to be good (one gets what one would expect).
    
    While one could argue that 'find_closest()' should not be used for arrays
    with progressions of 1 (i.e. '{1, 2, 3, ...}', the macro should still
    behave correctly.
    
    The bug was found while testing the 'drivers/iio/adc/ad7606.c',
    specifically the oversampling feature.
    For reference, the oversampling values are listed as:
       static const unsigned int ad7606_oversampling_avail[7] = {
              1, 2, 4, 8, 16, 32, 64,
       };
    
    When doing:
      1. $ echo 1 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         1  # this is fine
      2. $ echo 2 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         1  # this is wrong; 2 should be returned here
      3. $ echo 3 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         2  # this is fine
      4. $ echo 4 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio
         4  # this is fine
    And from here-on, the values are as correct (one gets what one would
    expect.)
    
    While writing a kunit test for this bug, a peculiar issue was found for the
    array in the 'drivers/hwmon/ina2xx.c' & 'drivers/iio/adc/ina2xx-adc.c'
    drivers. While running the kunit test (for 'ina226_avg_tab' from these
    drivers):
      * idx = find_closest([-1 to 2], ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab));
        This returns idx == 0, so value.
      * idx = find_closest(3, ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab));
        This returns idx == 0, value 1; and now one could argue whether 3 is
        closer to 4 or to 1. This quirk only appears for value '3' in this
        array, but it seems to be a another rounding issue.
      * And from 4 onwards the 'find_closest'() works fine (one gets what one
        would expect).
    
    This change reworks the find_closest() macros to also check the difference
    between the left and right elements when 'x'. If the distance to the right
    is smaller (than the distance to the left), the index is incremented by 1.
    This also makes redundant the need for using the DIV_ROUND_CLOSEST() macro.
    
    In order to accommodate for any mix of negative + positive values, the
    internal variables '__fc_x', '__fc_mid_x', '__fc_left' & '__fc_right' are
    forced to 'long' type. This also addresses any potential bugs/issues with
    'x' being of an unsigned type. In those situations any comparison between
    signed & unsigned would be promoted to a comparison between 2 unsigned
    numbers; this is especially annoying when '__fc_left' & '__fc_right'
    underflow.
    
    The find_closest_descending() macro was also reworked and duplicated from
    the find_closest(), and it is being iterated in reverse. The main reason
    for this is to get the same indices as 'find_closest()' (but in reverse).
    The comparison for '__fc_right < __fc_left' favors going the array in
    ascending order.
    For example for array '{ 1024, 512, 256, 128, 64, 16, 4, 1 }' and x = 3, we
    get:
        __fc_mid_x = 2
        __fc_left = -1
        __fc_right = -2
        Then '__fc_right < __fc_left' evaluates to true and '__fc_i++' becomes 7
        which is not quite incorrect, but 3 is closer to 4 than to 1.
    
    This change has been validated with the kunit from the next patch.
    
    Link: https://lkml.kernel.org/r/20241105145406.554365-1-aardelean@baylibre.com
    Fixes: 95d119528b0b ("util_macros.h: add find_closest() macro")
    Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
    Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 051762925e40c682aef30a3155339fb6e771570e
Author: Patrick Donnelly <pdonnell@redhat.com>
Date:   Sat Oct 12 20:54:11 2024 -0400

    ceph: extract entity name from device id
    
    commit 955710afcb3bb63e21e186451ed5eba85fa14d0b upstream.
    
    Previously, the "name" in the new device syntax "<name>@<fsid>.<fsname>"
    was ignored because (presumably) tests were done using mount.ceph which
    also passed the entity name using "-o name=foo". If mounting is done
    without the mount.ceph helper, the new device id syntax fails to set
    the name properly.
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/68516
    Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 213f22fb42530eed099b8acae9315e776bbcc791
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Wed Oct 23 13:05:34 2024 +0100

    ARM: 9431/1: mm: Pair atomic_set_release() with _read_acquire()
    
    commit 93ee385254d53849c01dd8ab9bc9d02790ee7f0e upstream.
    
    The code for syncing vmalloc memory PGD pointers is using
    atomic_read() in pair with atomic_set_release() but the
    proper pairing is atomic_read_acquire() paired with
    atomic_set_release().
    
    This is done to clearly instruct the compiler to not
    reorder the memcpy() or similar calls inside the section
    so that we do not observe changes to init_mm. memcpy()
    calls should be identified by the compiler as having
    unpredictable side effects, but let's try to be on the
    safe side.
    
    Cc: stable@vger.kernel.org
    Fixes: d31e23aff011 ("ARM: mm: make vmalloc_seq handling SMP safe")
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fe148d39c127de3fb78dfa6da95a3608dfda454
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Wed Oct 23 13:04:44 2024 +0100

    ARM: 9430/1: entry: Do a dummy read from VMAP shadow
    
    commit 44e9a3bb76e5f2eecd374c8176b2c5163c8bb2e2 upstream.
    
    When switching task, in addition to a dummy read from the new
    VMAP stack, also do a dummy read from the VMAP stack's
    corresponding KASAN shadow memory to sync things up in
    the new MM context.
    
    Cc: stable@vger.kernel.org
    Fixes: a1c510d0adc6 ("ARM: implement support for vmap'ed stacks")
    Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/
    Reported-by: Clement LE GOFFIC <clement.legoffic@foss.st.com>
    Suggested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb7a2c3afcf8732dc65ea49c09147b07da1d993
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Nov 19 14:54:07 2024 +0100

    s390/entry: Mark IRQ entries to fix stack depot warnings
    
    commit 45c9f2b856a075a34873d00788d2e8a250c1effd upstream.
    
    The stack depot filters out everything outside of the top interrupt
    context as an uninteresting or irrelevant part of the stack traces. This
    helps with stack trace de-duplication, avoiding an explosion of saved
    stack traces that share the same IRQ context code path but originate
    from different randomly interrupted points, eventually exhausting the
    stack depot.
    
    Filtering uses in_irqentry_text() to identify functions within the
    .irqentry.text and .softirqentry.text sections, which then become the
    last stack trace entries being saved.
    
    While __do_softirq() is placed into the .softirqentry.text section by
    common code, populating .irqentry.text is architecture-specific.
    
    Currently, the .irqentry.text section on s390 is empty, which prevents
    stack depot filtering and de-duplication and could result in warnings
    like:
    
    Stack depot reached limit capacity
    WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8
    
    with PREEMPT and KASAN enabled.
    
    Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into
    the .irqentry.text section and updating the kprobes blacklist to include
    the .irqentry.text section.
    
    This is done only for asynchronous interrupts and explicitly not for
    program checks, which are synchronous and where the context beyond the
    program check is important to preserve. Despite machine checks being
    somewhat in between, they are extremely rare, and preserving context
    when possible is also of value.
    
    SVCs and Restart Interrupts are not relevant, one being always at the
    boundary to user space and the other being a one-time thing.
    
    IRQ entries filtering is also optionally used in ftrace function graph,
    where the same logic applies.
    
    Cc: stable@vger.kernel.org # 5.15+
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95c98e7ab84686d3a7ddd92c7bb6a2dae5034b7a
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Wed Oct 23 13:03:14 2024 +0100

    ARM: 9429/1: ioremap: Sync PGDs for VMALLOC shadow
    
    commit d6e6a74d4cea853b5321eeabb69c611148eedefe upstream.
    
    When sync:ing the VMALLOC area to other CPUs, make sure to also
    sync the KASAN shadow memory for the VMALLOC area, so that we
    don't get stale entries for the shadow memory in the top level PGD.
    
    Since we are now copying PGDs in two instances, create a helper
    function named memcpy_pgd() to do the actual copying, and
    create a helper to map the addresses of VMALLOC_START and
    VMALLOC_END into the corresponding shadow memory.
    
    Co-developed-by: Melon Liu <melon1335@163.com>
    
    Cc: stable@vger.kernel.org
    Fixes: 565cbaad83d8 ("ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC")
    Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/
    Reported-by: Clement LE GOFFIC <clement.legoffic@foss.st.com>
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 022e13518ba6cc1b4fdd291f49e4f57b2d5718e0
Author: Zicheng Qu <quzicheng@huawei.com>
Date:   Mon Oct 28 14:20:27 2024 +0000

    ad7780: fix division by zero in ad7780_write_raw()
    
    commit c174b53e95adf2eece2afc56cd9798374919f99a upstream.
    
    In the ad7780_write_raw() , val2 can be zero, which might lead to a
    division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()
    is based on iio_info's write_raw. While val is explicitly declared that
    can be zero (in read mode), val2 is not specified to be non-zero.
    
    Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zicheng Qu <quzicheng@huawei.com>
    Link: https://patch.msgid.link/20241028142027.1032332-1-quzicheng@huawei.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c028c1bf802391a78336db520e6155e5b452ea8
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Tue Oct 22 11:45:56 2024 +0200

    clk: qcom: gcc-qcs404: fix initial rate of GPLL3
    
    commit 36d202241d234fa4ac50743510d098ad52bd193a upstream.
    
    The comment before the config of the GPLL3 PLL says that the
    PLL should run at 930 MHz. In contrary to this, calculating
    the frequency from the current configuration values by using
    19.2 MHz as input frequency defined in 'qcs404.dtsi', it gives
    921.6 MHz:
    
      $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x0
      $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l
      921600000.00000000000000000000
    
    Set 'alpha_hi' in the configuration to a value used in downstream
    kernels [1][2] in order to get the correct output rate:
    
      $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x70
      $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l
      930000000.00000000000000000000
    
    The change is based on static code analysis, compile tested only.
    
    [1] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/kernel.lnx.5.4.r56-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L335
    [2} https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r49-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L127
    
    Cc: stable@vger.kernel.org
    Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Link: https://lore.kernel.org/r/20241022-fix-gcc-qcs404-gpll3-v1-1-c4d30d634d19@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 133be7fa5abe1cd5944d945eceef425f2fea6545
Author: Michal Vokáč <michal.vokac@ysoft.com>
Date:   Thu Oct 17 17:08:12 2024 +0200

    leds: lp55xx: Remove redundant test for invalid channel number
    
    commit 09b1ef9813a0742674f7efe26104403ca94a1b4a upstream.
    
    Since commit 92a81562e695 ("leds: lp55xx: Add multicolor framework
    support to lp55xx") there are two subsequent tests if the chan_nr
    (reg property) is in valid range. One in the lp55xx_init_led()
    function and one in the lp55xx_parse_common_child() function that
    was added with the mentioned commit.
    
    There are two issues with that.
    
    First is in the lp55xx_parse_common_child() function where the reg
    property is tested right after it is read from the device tree.
    Test for the upper range is not correct though. Valid reg values are
    0 to (max_channel - 1) so it should be >=.
    
    Second issue is that in case the parsed value is out of the range
    the probe just fails and no error message is shown as the code never
    reaches the second test that prints and error message.
    
    Remove the test form lp55xx_parse_common_child() function completely
    and keep the one in lp55xx_init_led() function to deal with it.
    
    Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx")
    Cc: stable@vger.kernel.org
    Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
    Link: https://lore.kernel.org/r/20241017150812.3563629-1-michal.vokac@ysoft.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34e18de94b9cdd415f2e8f600d7e00de7805234f
Author: Mostafa Saleh <smostafa@google.com>
Date:   Thu Oct 24 16:25:15 2024 +0000

    iommu/io-pgtable-arm: Fix stage-2 map/unmap for concatenated tables
    
    commit d71fa842d33c48ac2809ae11d2379b5a788792cb upstream.
    
    ARM_LPAE_LVL_IDX() takes into account concatenated PGDs and can return
    an index spanning multiple page-table pages given a sufficiently large
    input address. However, when the resulting index is used to calculate
    the number of remaining entries in the page, the possibility of
    concatenation is ignored and we end up computing a negative upper bound:
    
            max_entries = ARM_LPAE_PTES_PER_TABLE(data) - map_idx_start;
    
    On the map path, this results in a negative 'mapped' value being
    returned but on the unmap path we can leak child tables if they are
    skipped in __arm_lpae_free_pgtable().
    
    Introduce an arm_lpae_max_entries() helper to convert a table index into
    the remaining number of entries within a single page-table page.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mostafa Saleh <smostafa@google.com>
    Link: https://lore.kernel.org/r/20241024162516.2005652-2-smostafa@google.com
    [will: Tweaked comment and commit message]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df8796f1cc8928596696ef57879e53c9a0c1663c
Author: MengEn Sun <mengensun@tencent.com>
Date:   Fri Nov 1 12:06:38 2024 +0800

    vmstat: call fold_vm_zone_numa_events() before show per zone NUMA event
    
    commit 2ea80b039b9af0b71c00378523b71c254fb99c23 upstream.
    
    Since 5.14-rc1, NUMA events will only be folded from per-CPU statistics to
    per zone and global statistics when the user actually needs it.
    
    Currently, the kernel has performs the fold operation when reading
    /proc/vmstat, but does not perform the fold operation in /proc/zoneinfo.
    This can lead to inaccuracies in the following statistics in zoneinfo:
    - numa_hit
    - numa_miss
    - numa_foreign
    - numa_interleave
    - numa_local
    - numa_other
    
    Therefore, before printing per-zone vm_numa_event when reading
    /proc/zoneinfo, we should also perform the fold operation.
    
    Link: https://lkml.kernel.org/r/1730433998-10461-1-git-send-email-mengensun@tencent.com
    Fixes: f19298b9516c ("mm/vmstat: convert NUMA statistics to basic NUMA counters")
    Signed-off-by: MengEn Sun <mengensun@tencent.com>
    Reviewed-by: JinLiang Zheng <alexjlzheng@tencent.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ae27880de3482e063fcc1f72d9a298d0d391407
Author: guoweikang <guoweikang.kernel@gmail.com>
Date:   Wed Nov 20 13:27:49 2024 +0800

    ftrace: Fix regression with module command in stack_trace_filter
    
    commit 45af52e7d3b8560f21d139b3759735eead8b1653 upstream.
    
    When executing the following command:
    
        # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter
    
    The current mod command causes a null pointer dereference. While commit
    0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")
    has addressed part of the issue, it left a corner case unhandled, which still
    results in a kernel crash.
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Link: https://lore.kernel.org/20241120052750.275463-1-guoweikang.kernel@gmail.com
    Fixes: 04ec7bb642b77 ("tracing: Have the trace_array hold the list of registered func probes");
    Signed-off-by: guoweikang <guoweikang.kernel@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 459904a8732cfdd839b74c4a3a29c6af7f99ab34
Author: Wei Yang <richard.weiyang@gmail.com>
Date:   Thu Oct 31 23:16:26 2024 +0000

    maple_tree: refine mas_store_root() on storing NULL
    
    commit 0ea120b278ad7f7cfeeb606e150ad04b192df60b upstream.
    
    Currently, when storing NULL on mas_store_root(), the behavior could be
    improved.
    
    Storing NULLs over the entire tree may result in a node being used to
    store a single range.  Further stores of NULL may cause the node and
    tree to be corrupt and cause incorrect behaviour.  Fixing the store to
    the root null fixes the issue by ensuring that a range of 0 - ULONG_MAX
    results in an empty tree.
    
    Users of the tree may experience incorrect values returned if the tree
    was expanded to store values, then overwritten by all NULLS, then
    continued to store NULLs over the empty area.
    
    For example possible cases are:
    
      * store NULL at any range result a new node
      * store NULL at range [m, n] where m > 0 to a single entry tree result
        a new node with range [m, n] set to NULL
      * store NULL at range [m, n] where m > 0 to an empty tree result
        consecutive NULL slot
      * it allows for multiple NULL entries by expanding root
        to store NULLs to an empty tree
    
    This patch tries to improve in:
    
      * memory efficient by setting to empty tree instead of using a node
      * remove the possibility of consecutive NULL slot which will prohibit
        extended null in later operation
    
    Link: https://lkml.kernel.org/r/20241031231627.14316-5-richard.weiyang@gmail.com
    Fixes: 54a611b60590 ("Maple Tree: add new data structure")
    Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
    Cc: Liam R. Howlett <Liam.Howlett@Oracle.com>
    Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
    Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff43d008bbf9b27ada434d6455f039a5ef6cee53
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Tue Nov 19 18:58:17 2024 +0300

    ovl: Filter invalid inodes with missing lookup function
    
    commit c8b359dddb418c60df1a69beea01d1b3322bfe83 upstream.
    
    Add a check to the ovl_dentry_weird() function to prevent the
    processing of directory inodes that lack the lookup function.
    This is important because such inodes can cause errors in overlayfs
    when passed to the lowerstack.
    
    Reported-by: syzbot+a8c9d476508bd14a90e5@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=a8c9d476508bd14a90e5
    Suggested-by: Miklos Szeredi <miklos@szeredi.hu>
    Link: https://lore.kernel.org/linux-unionfs/CAJfpegvx-oS9XGuwpJx=Xe28_jzWx5eRo1y900_ZzWY+=gGzUg@mail.gmail.com/
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19464d73225224dca31e2fd6e7d6418facf5facb
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri Sep 13 15:06:01 2024 -0300

    media: uvcvideo: Require entities to have a non-zero unique ID
    
    commit 3dd075fe8ebbc6fcbf998f81a75b8c4b159a6195 upstream.
    
    Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
    unique ID.
    
    ```
    Each Unit and Terminal within the video function is assigned a unique
    identification number, the Unit ID (UID) or Terminal ID (TID), contained in
    the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
    reserved for undefined ID,
    ```
    
    So, deny allocating an entity with ID 0 or an ID that belongs to a unit
    that is already added to the list of entities.
    
    This also prevents some syzkaller reproducers from triggering warnings due
    to a chain of entities referring to themselves. In one particular case, an
    Output Unit is connected to an Input Unit, both with the same ID of 1. But
    when looking up for the source ID of the Output Unit, that same entity is
    found instead of the input entity, which leads to such warnings.
    
    In another case, a backward chain was considered finished as the source ID
    was 0. Later on, that entity was found, but its pads were not valid.
    
    Here is a sample stack trace for one of those cases.
    
    [   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
    [   20.830206] usb 1-1: Using ep0 maxpacket: 8
    [   20.833501] usb 1-1: config 0 descriptor??
    [   21.038518] usb 1-1: string descriptor 0 read error: -71
    [   21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201)
    [   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!
    [   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!
    [   21.042218] ------------[ cut here ]------------
    [   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0
    [   21.043195] Modules linked in:
    [   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444
    [   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    [   21.044639] Workqueue: usb_hub_wq hub_event
    [   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0
    [   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00
    [   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246
    [   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1
    [   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290
    [   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000
    [   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003
    [   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000
    [   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000
    [   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0
    [   21.051136] PKRU: 55555554
    [   21.051331] Call Trace:
    [   21.051480]  <TASK>
    [   21.051611]  ? __warn+0xc4/0x210
    [   21.051861]  ? media_create_pad_link+0x2c4/0x2e0
    [   21.052252]  ? report_bug+0x11b/0x1a0
    [   21.052540]  ? trace_hardirqs_on+0x31/0x40
    [   21.052901]  ? handle_bug+0x3d/0x70
    [   21.053197]  ? exc_invalid_op+0x1a/0x50
    [   21.053511]  ? asm_exc_invalid_op+0x1a/0x20
    [   21.053924]  ? media_create_pad_link+0x91/0x2e0
    [   21.054364]  ? media_create_pad_link+0x2c4/0x2e0
    [   21.054834]  ? media_create_pad_link+0x91/0x2e0
    [   21.055131]  ? _raw_spin_unlock+0x1e/0x40
    [   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210
    [   21.055837]  uvc_mc_register_entities+0x358/0x400
    [   21.056144]  uvc_register_chains+0x1fd/0x290
    [   21.056413]  uvc_probe+0x380e/0x3dc0
    [   21.056676]  ? __lock_acquire+0x5aa/0x26e0
    [   21.056946]  ? find_held_lock+0x33/0xa0
    [   21.057196]  ? kernfs_activate+0x70/0x80
    [   21.057533]  ? usb_match_dynamic_id+0x1b/0x70
    [   21.057811]  ? find_held_lock+0x33/0xa0
    [   21.058047]  ? usb_match_dynamic_id+0x55/0x70
    [   21.058330]  ? lock_release+0x124/0x260
    [   21.058657]  ? usb_match_one_id_intf+0xa2/0x100
    [   21.058997]  usb_probe_interface+0x1ba/0x330
    [   21.059399]  really_probe+0x1ba/0x4c0
    [   21.059662]  __driver_probe_device+0xb2/0x180
    [   21.059944]  driver_probe_device+0x5a/0x100
    [   21.060170]  __device_attach_driver+0xe9/0x160
    [   21.060427]  ? __pfx___device_attach_driver+0x10/0x10
    [   21.060872]  bus_for_each_drv+0xa9/0x100
    [   21.061312]  __device_attach+0xed/0x190
    [   21.061812]  device_initial_probe+0xe/0x20
    [   21.062229]  bus_probe_device+0x4d/0xd0
    [   21.062590]  device_add+0x308/0x590
    [   21.062912]  usb_set_configuration+0x7b6/0xaf0
    [   21.063403]  usb_generic_driver_probe+0x36/0x80
    [   21.063714]  usb_probe_device+0x7b/0x130
    [   21.063936]  really_probe+0x1ba/0x4c0
    [   21.064111]  __driver_probe_device+0xb2/0x180
    [   21.064577]  driver_probe_device+0x5a/0x100
    [   21.065019]  __device_attach_driver+0xe9/0x160
    [   21.065403]  ? __pfx___device_attach_driver+0x10/0x10
    [   21.065820]  bus_for_each_drv+0xa9/0x100
    [   21.066094]  __device_attach+0xed/0x190
    [   21.066535]  device_initial_probe+0xe/0x20
    [   21.066992]  bus_probe_device+0x4d/0xd0
    [   21.067250]  device_add+0x308/0x590
    [   21.067501]  usb_new_device+0x347/0x610
    [   21.067817]  hub_event+0x156b/0x1e30
    [   21.068060]  ? process_scheduled_works+0x48b/0xaf0
    [   21.068337]  process_scheduled_works+0x5a3/0xaf0
    [   21.068668]  worker_thread+0x3cf/0x560
    [   21.068932]  ? kthread+0x109/0x1b0
    [   21.069133]  kthread+0x197/0x1b0
    [   21.069343]  ? __pfx_worker_thread+0x10/0x10
    [   21.069598]  ? __pfx_kthread+0x10/0x10
    [   21.069908]  ret_from_fork+0x32/0x40
    [   21.070169]  ? __pfx_kthread+0x10/0x10
    [   21.070424]  ret_from_fork_asm+0x1a/0x30
    [   21.070737]  </TASK>
    
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+0584f746fde3d52b4675@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0584f746fde3d52b4675
    Reported-by: syzbot+dd320d114deb3f5bb79b@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=dd320d114deb3f5bb79b
    Fixes: a3fbc2e6bb05 ("media: mc-entity.c: use WARN_ON, validate link pads")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240913180601.1400596-2-cascardo@igalia.com
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5aad0a6b59a417518f0152a37f2f60f0f54bee90
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Sep 26 05:59:06 2024 +0000

    media: uvcvideo: Stop stream during unregister
    
    commit c9ec6f1736363b2b2bb4e266997389740f628441 upstream.
    
    uvc_unregister_video() can be called asynchronously from
    uvc_disconnect(). If the device is still streaming when that happens, a
    plethora of race conditions can occur.
    
    Make sure that the device has stopped streaming before exiting this
    function.
    
    If the user still holds handles to the driver's file descriptors, any
    ioctl will return -ENODEV from the v4l2 core.
    
    This change makes uvc more consistent with the rest of the v4l2 drivers
    using the vb2_fop_* and vb2_ioctl_* helpers.
    
    This driver (and many other usb drivers) always had this problem, but it
    wasn't possible to easily fix this until the vb2_video_unregister_device()
    helper was added. So the Fixes tag points to the creation of that helper.
    
    Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
    Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Fixes: f729ef5796d8 ("media: videobuf2-v4l2.c: add vb2_video_unregister_device helper function")
    Cc: stable@vger.kernel.org # 5.10.x
    [hverkuil: add note regarding Fixes version]
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17e5613666209be4e5be1f1894f1a6014a8a0658
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Wed Oct 9 16:28:02 2024 +0800

    media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
    
    commit 0f514068fbc5d4d189c817adc7c4e32cffdc2e47 upstream.
    
    The buffer in the loop should be released under the exception path,
    otherwise there may be a memory leak here.
    
    To mitigate this, free the buffer when allegro_alloc_buffer fails.
    
    Fixes: f20387dfd065 ("media: allegro: add Allegro DVT video IP core driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71d0e403f6e6b0fc31ac0a62e9f9a20caea018aa
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Oct 28 16:02:56 2024 +0800

    media: gspca: ov534-ov772x: Fix off-by-one error in set_frame_rate()
    
    commit d2842dec577900031826dc44e9bf0c66416d7173 upstream.
    
    In set_frame_rate(), select a rate in rate_0 or rate_1 by checking
    sd->frame_rate >= r->fps in a loop, but the loop condition terminates when
    the index reaches zero, which fails to check the last elememt in rate_0 or
    rate_1.
    
    Check for >= 0 so that the last one in rate_0 or rate_1 is also checked.
    
    Fixes: 189d92af707e ("V4L/DVB (13422): gspca - ov534: ov772x changes from Richard Kaswy.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbbc4f745902ed0aa320db47a110a81753a056bb
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Nov 1 17:40:50 2024 +0800

    media: venus: Fix pm_runtime_set_suspended() with runtime pm enabled
    
    commit 2a20869f7d798aa2b69e45b863eaf1b1ecf98278 upstream.
    
    It is not valid to call pm_runtime_set_suspended() for devices
    with runtime PM enabled because it returns -EAGAIN if it is enabled
    already and working. So, call pm_runtime_disable() before to fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c72d1cd2bef4943f7fc30b07ef8928de6cc2a26f
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Nov 1 17:40:49 2024 +0800

    media: amphion: Fix pm_runtime_set_suspended() with runtime pm enabled
    
    commit 316e74500d1c6589cba28cebe2864a0bceeb2396 upstream.
    
    It is not valid to call pm_runtime_set_suspended() for devices
    with runtime PM enabled because it returns -EAGAIN if it is enabled
    already and working. So, call pm_runtime_disable() before to fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: b50a64fc54af ("media: amphion: add amphion vpu device driver")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2155e919245e2c141a500df257e38a59efdf73db
Author: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Date:   Mon Nov 4 19:01:19 2024 +0900

    media: platform: exynos4-is: Fix an OF node reference leak in fimc_md_is_isp_available
    
    commit 8964eb23408243ae0016d1f8473c76f64ff25d20 upstream.
    
    In fimc_md_is_isp_available(), of_get_child_by_name() is called to check
    if FIMC-IS is available. Current code does not decrement the refcount of
    the returned device node, which causes an OF node reference leak. Fix it
    by calling of_node_put() at the end of the variable scope.
    
    Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
    Fixes: e781bbe3fecf ("[media] exynos4-is: Add fimc-is subdevs registration")
    Cc: stable@vger.kernel.org
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    [hverkuil: added CC to stable]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc03866b5f4aa2668946f8384a1e5286ae53bbaa
Author: Li Zetao <lizetao1@huawei.com>
Date:   Thu Oct 10 23:41:13 2024 +0800

    media: ts2020: fix null-ptr-deref in ts2020_probe()
    
    commit 4a058b34b52ed3feb1f3ff6fd26aefeeeed20cba upstream.
    
    KASAN reported a null-ptr-deref issue when executing the following
    command:
    
      # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
        KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
        CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
        Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
        RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
        RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
        RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
        RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010
        RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6
        R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790
        R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001
        FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         <TASK>
         ts2020_probe+0xad/0xe10 [ts2020]
         i2c_device_probe+0x421/0xb40
         really_probe+0x266/0x850
        ...
    
    The cause of the problem is that when using sysfs to dynamically register
    an i2c device, there is no platform data, but the probe process of ts2020
    needs to use platform data, resulting in a null pointer being accessed.
    
    Solve this problem by adding checks to platform data.
    
    Fixes: dc245a5f9b51 ("[media] ts2020: implement I2C client bindings")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12914fd765ba4f9d6a9a50439e8dd2e9f91423f2
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Sep 13 15:22:54 2024 +0900

    media: imx-jpeg: Ensure power suppliers be suspended before detach them
    
    commit fd0af4cd35da0eb550ef682b71cda70a4e36f6b9 upstream.
    
    The power suppliers are always requested to suspend asynchronously,
    dev_pm_domain_detach() requires the caller to ensure proper
    synchronization of this function with power management callbacks.
    otherwise the detach may led to kernel panic, like below:
    
    [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040
    [ 1457.116777] Mem abort info:
    [ 1457.119589]   ESR = 0x0000000096000004
    [ 1457.123358]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 1457.128692]   SET = 0, FnV = 0
    [ 1457.131764]   EA = 0, S1PTW = 0
    [ 1457.134920]   FSC = 0x04: level 0 translation fault
    [ 1457.139812] Data abort info:
    [ 1457.142707]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    [ 1457.148196]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [ 1457.153256]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000
    [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000
    [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    [ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec]
    [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66
    [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)
    [ 1457.199236] Workqueue: pm pm_runtime_work
    [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290
    [ 1457.214886] lr : __rpm_callback+0x48/0x1d8
    [ 1457.218968] sp : ffff80008250bc50
    [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000
    [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240
    [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008
    [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff
    [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674
    [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002
    [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0
    [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000
    [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000
    [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000
    [ 1457.293510] Call trace:
    [ 1457.295946]  genpd_runtime_suspend+0x20/0x290
    [ 1457.300296]  __rpm_callback+0x48/0x1d8
    [ 1457.304038]  rpm_callback+0x6c/0x78
    [ 1457.307515]  rpm_suspend+0x10c/0x570
    [ 1457.311077]  pm_runtime_work+0xc4/0xc8
    [ 1457.314813]  process_one_work+0x138/0x248
    [ 1457.318816]  worker_thread+0x320/0x438
    [ 1457.322552]  kthread+0x110/0x114
    [ 1457.325767]  ret_from_fork+0x10/0x20
    
    Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: TaoJiang <tao.jiang_2@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34a3466a92f50c51d984f0ec2e96864886d460eb
Author: Alexander Shiyan <eagle.alexander923@gmail.com>
Date:   Wed Oct 9 09:05:44 2024 +0300

    media: i2c: tc358743: Fix crash in the probe error path when using polling
    
    commit 869f38ae07f7df829da4951c3d1f7a2be09c2e9a upstream.
    
    If an error occurs in the probe() function, we should remove the polling
    timer that was alarmed earlier, otherwise the timer is called with
    arguments that are already freed, which results in a crash.
    
    ------------[ cut here ]------------
    WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268
    Modules linked in:
    CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226
    Hardware name: Diasom DS-RK3568-SOM-EVB (DT)
    pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __run_timers+0x244/0x268
    lr : __run_timers+0x1d4/0x268
    sp : ffffff80eff2baf0
    x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00
    x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00
    x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000
    x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff
    x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e
    x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000
    x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009
    x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480
    x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240
    x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0
    Call trace:
     __run_timers+0x244/0x268
     timer_expire_remote+0x50/0x68
     tmigr_handle_remote+0x388/0x39c
     run_timer_softirq+0x38/0x44
     handle_softirqs+0x138/0x298
     __do_softirq+0x14/0x20
     ____do_softirq+0x10/0x1c
     call_on_irq_stack+0x24/0x4c
     do_softirq_own_stack+0x1c/0x2c
     irq_exit_rcu+0x9c/0xcc
     el1_interrupt+0x48/0xc0
     el1h_64_irq_handler+0x18/0x24
     el1h_64_irq+0x7c/0x80
     default_idle_call+0x34/0x68
     do_idle+0x23c/0x294
     cpu_startup_entry+0x38/0x3c
     secondary_start_kernel+0x128/0x160
     __secondary_switched+0xb8/0xbc
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 4e66a52a2e4c ("[media] tc358743: Add support for platforms without IRQ line")
    Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eb254505debc101e0475b35442c41cc9901226a
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Thu Oct 24 15:06:51 2024 +0200

    arm64: dts: freescale: imx8mp-verdin: Fix SD regulator startup delay
    
    commit 6c5789c9d2c06968532243daa235f6ff809ad71e upstream.
    
    The power switch used to power the SD card interface might have
    more than 2ms turn-on time, increase the startup delay to 20ms to
    prevent failures.
    
    Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus")
    Cc: stable@vger.kernel.org
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90b73f02f39f12de4c016040fa005c4c33e8286
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Nov 1 17:40:48 2024 +0800

    media: i2c: dw9768: Fix pm_runtime_set_suspended() with runtime pm enabled
    
    commit d6594d50761728d09f23238cf9c368bab6260ef3 upstream.
    
    It is not valid to call pm_runtime_set_suspended() and
    pm_runtime_set_active() for devices with runtime PM enabled because it
    returns -EAGAIN if it is enabled already and working. So, adjust the
    order to fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: 5f9a089b6de3 ("dw9768: Enable low-power probe on ACPI")
    Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b88556e82dc18cb708744d062770853a2d5095b2
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Sep 13 15:21:44 2024 +0900

    media: imx-jpeg: Set video drvdata before register video device
    
    commit d2b7ecc26bd5406d5ba927be1748aa99c568696c upstream.
    
    The video drvdata should be set before the video device is registered,
    otherwise video_drvdata() may return NULL in the open() file ops, and led
    to oops.
    
    Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: TaoJiang <tao.jiang_2@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfe96c7c3382293179e291f66644d789e39e99f3
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Sep 13 15:21:45 2024 +0900

    media: amphion: Set video drvdata before register video device
    
    commit 8cbb1a7bd5973b57898b26eb804fe44af440bb63 upstream.
    
    The video drvdata should be set before the video device is registered,
    otherwise video_drvdata() may return NULL in the open() file ops, and led
    to oops.
    
    Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    Reviewed-by: TaoJiang <tao.jiang_2@nxp.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ca8299aa7d39a20775993b744c241e6a2a1bbbc
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Thu Oct 24 15:06:50 2024 +0200

    arm64: dts: freescale: imx8mm-verdin: Fix SD regulator startup delay
    
    commit 0ca7699c376743b633b6419a42888dba386d5351 upstream.
    
    The power switch used to power the SD card interface might have
    more than 2ms turn-on time, increase the startup delay to 20ms to
    prevent failures.
    
    Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini")
    Cc: stable@vger.kernel.org
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f1fcc102144746dafb6b5a37a2927893b0c5fcd
Author: Dragan Simic <dsimic@manjaro.org>
Date:   Thu Sep 19 21:15:26 2024 +0200

    arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer
    
    commit 2496b2aaacf137250f4ca449f465e2cadaabb0e8 upstream.
    
    The way InvenSense MPU-6050 accelerometer is mounted on the user-facing side
    of the Pine64 PinePhone mainboard, which makes it rotated 90 degrees counter-
    clockwise, [1] requires the accelerometer's x- and y-axis to be swapped, and
    the direction of the accelerometer's y-axis to be inverted.
    
    Rectify this by adding a mount-matrix to the accelerometer definition in the
    Pine64 PinePhone dtsi file.
    
    [1] https://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20placement%20v1.1%2020191031.pdf
    
    Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone")
    Cc: stable@vger.kernel.org
    Suggested-by: Ondrej Jirman <megi@xff.cz>
    Suggested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
    Link: https://patch.msgid.link/129f0c754d071cca1db5d207d9d4a7bd9831dff7.1726773282.git.dsimic@manjaro.org
    [wens@csie.org: Replaced Helped-by with Suggested-by]
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6370db28af9a8ae3bbdfe97f8a48f8f995e144cf
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Nov 15 11:29:21 2024 +0000

    btrfs: ref-verify: fix use-after-free after invalid ref action
    
    [ Upstream commit 7c4e39f9d2af4abaf82ca0e315d1fd340456620f ]
    
    At btrfs_ref_tree_mod() after we successfully inserted the new ref entry
    (local variable 'ref') into the respective block entry's rbtree (local
    variable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,
    we error out and free the ref entry without removing it from the block
    entry's rbtree. Then in the error path of btrfs_ref_tree_mod() we call
    btrfs_free_ref_cache(), which iterates over all block entries and then
    calls free_block_entry() for each one, and there we will trigger a
    use-after-free when we are called against the block entry to which we
    added the freed ref entry to its rbtree, since the rbtree still points
    to the block entry, as we didn't remove it from the rbtree before freeing
    it in the error path at btrfs_ref_tree_mod(). Fix this by removing the
    new ref entry from the rbtree before freeing it.
    
    Syzbot report this with the following stack traces:
    
       BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615
          __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
          update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
          btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
          btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
          btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
          btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314
          btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]
          btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23
          btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482
          btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293
          vfs_unlink+0x365/0x650 fs/namei.c:4469
          do_unlinkat+0x4ae/0x830 fs/namei.c:4533
          __do_sys_unlinkat fs/namei.c:4576 [inline]
          __se_sys_unlinkat fs/namei.c:4569 [inline]
          __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569
          do_syscall_x64 arch/x86/entry/common.c:52 [inline]
          do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
          entry_SYSCALL_64_after_hwframe+0x77/0x7f
       BTRFS error (device loop0 state EA):   Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1
          __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521
          update_ref_for_cow+0x96a/0x11f0
          btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
          btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
          btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
          btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
          __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
          btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
          __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
          __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
          btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
          prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
          relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
          btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
          btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
          __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
          btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
       BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615
          __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
          update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
          btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
          btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
          btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
          btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
          __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
          btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
          __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
          __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
          btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
          prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
          relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
          btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
          btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
          __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
          btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
       ==================================================================
       BUG: KASAN: slab-use-after-free in rb_first+0x69/0x70 lib/rbtree.c:473
       Read of size 8 at addr ffff888042d1af38 by task syz.0.0/5329
    
       CPU: 0 UID: 0 PID: 5329 Comm: syz.0.0 Not tainted 6.12.0-rc7-syzkaller #0
       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
       Call Trace:
        <TASK>
        __dump_stack lib/dump_stack.c:94 [inline]
        dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
        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
        rb_first+0x69/0x70 lib/rbtree.c:473
        free_block_entry+0x78/0x230 fs/btrfs/ref-verify.c:248
        btrfs_free_ref_cache+0xa3/0x100 fs/btrfs/ref-verify.c:917
        btrfs_ref_tree_mod+0x139f/0x15e0 fs/btrfs/ref-verify.c:898
        btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544
        __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
        update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
        btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
        btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
        btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
        btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
        __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
        btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
        __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
        __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
        btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
        prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
        relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
        btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
        btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
        __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
        btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
        btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:907 [inline]
        __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
        entry_SYSCALL_64_after_hwframe+0x77/0x7f
       RIP: 0033:0x7f996df7e719
       RSP: 002b:00007f996ede7038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
       RAX: ffffffffffffffda RBX: 00007f996e135f80 RCX: 00007f996df7e719
       RDX: 0000000020000180 RSI: 00000000c4009420 RDI: 0000000000000004
       RBP: 00007f996dff139e R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
       R13: 0000000000000000 R14: 00007f996e135f80 R15: 00007fff79f32e68
        </TASK>
    
       Allocated by task 5329:
        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:377 [inline]
        __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
        kasan_kmalloc include/linux/kasan.h:257 [inline]
        __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4295
        kmalloc_noprof include/linux/slab.h:878 [inline]
        kzalloc_noprof include/linux/slab.h:1014 [inline]
        btrfs_ref_tree_mod+0x264/0x15e0 fs/btrfs/ref-verify.c:701
        btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544
        __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
        update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
        btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
        btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
        btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
        btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
        __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
        btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
        __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
        __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
        btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
        prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
        relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
        btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
        btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
        __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
        btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
        btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:907 [inline]
        __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
        entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
       Freed by task 5329:
        kasan_save_stack mm/kasan/common.c:47 [inline]
        kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
        kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
        poison_slab_object mm/kasan/common.c:247 [inline]
        __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
        kasan_slab_free include/linux/kasan.h:230 [inline]
        slab_free_hook mm/slub.c:2342 [inline]
        slab_free mm/slub.c:4579 [inline]
        kfree+0x1a0/0x440 mm/slub.c:4727
        btrfs_ref_tree_mod+0x136c/0x15e0
        btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544
        __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523
        update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512
        btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594
        btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754
        btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116
        btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411
        __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030
        btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]
        __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137
        __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171
        btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313
        prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586
        relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611
        btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081
        btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377
        __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161
        btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538
        btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:907 [inline]
        __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
        entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
       The buggy address belongs to the object at ffff888042d1af00
        which belongs to the cache kmalloc-64 of size 64
       The buggy address is located 56 bytes inside of
        freed 64-byte region [ffff888042d1af00, ffff888042d1af40)
    
       The buggy address belongs to the physical page:
       page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x42d1a
       anon flags: 0x4fff00000000000(node=1|zone=1|lastcpupid=0x7ff)
       page_type: f5(slab)
       raw: 04fff00000000000 ffff88801ac418c0 0000000000000000 dead000000000001
       raw: 0000000000000000 0000000000200020 00000001f5000000 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 0x52c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 5055, tgid 5055 (dhcpcd-run-hook), ts 40377240074, free_ts 40376848335
        set_page_owner include/linux/page_owner.h:32 [inline]
        post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1541
        prep_new_page mm/page_alloc.c:1549 [inline]
        get_page_from_freelist+0x3649/0x3790 mm/page_alloc.c:3459
        __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4735
        alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
        alloc_slab_page+0x6a/0x140 mm/slub.c:2412
        allocate_slab+0x5a/0x2f0 mm/slub.c:2578
        new_slab mm/slub.c:2631 [inline]
        ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3818
        __slab_alloc+0x58/0xa0 mm/slub.c:3908
        __slab_alloc_node mm/slub.c:3961 [inline]
        slab_alloc_node mm/slub.c:4122 [inline]
        __do_kmalloc_node mm/slub.c:4263 [inline]
        __kmalloc_noprof+0x25a/0x400 mm/slub.c:4276
        kmalloc_noprof include/linux/slab.h:882 [inline]
        kzalloc_noprof include/linux/slab.h:1014 [inline]
        tomoyo_encode2 security/tomoyo/realpath.c:45 [inline]
        tomoyo_encode+0x26f/0x540 security/tomoyo/realpath.c:80
        tomoyo_realpath_from_path+0x59e/0x5e0 security/tomoyo/realpath.c:283
        tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
        tomoyo_check_open_permission+0x255/0x500 security/tomoyo/file.c:771
        security_file_open+0x777/0x990 security/security.c:3109
        do_dentry_open+0x369/0x1460 fs/open.c:945
        vfs_open+0x3e/0x330 fs/open.c:1088
        do_open fs/namei.c:3774 [inline]
        path_openat+0x2c84/0x3590 fs/namei.c:3933
       page last free pid 5055 tgid 5055 stack trace:
        reset_page_owner include/linux/page_owner.h:25 [inline]
        free_pages_prepare mm/page_alloc.c:1112 [inline]
        free_unref_page+0xcfb/0xf20 mm/page_alloc.c:2642
        free_pipe_info+0x300/0x390 fs/pipe.c:860
        put_pipe_info fs/pipe.c:719 [inline]
        pipe_release+0x245/0x320 fs/pipe.c:742
        __fput+0x23f/0x880 fs/file_table.c:431
        __do_sys_close fs/open.c:1567 [inline]
        __se_sys_close fs/open.c:1552 [inline]
        __x64_sys_close+0x7f/0x110 fs/open.c:1552
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
        entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
       Memory state around the buggy address:
        ffff888042d1ae00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
        ffff888042d1ae80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
       >ffff888042d1af00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
                                               ^
        ffff888042d1af80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
        ffff888042d1b000: 00 00 00 00 00 fc fc 00 00 00 00 00 fc fc 00 00
    
    Reported-by: syzbot+7325f164162e200000c1@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/673723eb.050a0220.1324f8.00a8.GAE@google.com/T/#u
    Fixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")
    CC: stable@vger.kernel.org # 4.19+
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db66fb87c21e8ae724886e6a464dcbac562a64c6
Author: Lizhi Xu <lizhi.xu@windriver.com>
Date:   Fri Oct 25 12:55:53 2024 +0800

    btrfs: add a sanity check for btrfs root in btrfs_search_slot()
    
    [ Upstream commit 3ed51857a50f530ac7a1482e069dfbd1298558d4 ]
    
    Syzbot reports a null-ptr-deref in btrfs_search_slot().
    
    The reproducer is using rescue=ibadroots, and the extent tree root is
    corrupted thus the extent tree is NULL.
    
    When scrub tries to search the extent tree to gather the needed extent
    info, btrfs_search_slot() doesn't check if the target root is NULL or
    not, resulting the null-ptr-deref.
    
    Add sanity check for btrfs root before using it in btrfs_search_slot().
    
    Reported-by: syzbot+3030e17bd57a73d39bd7@syzkaller.appspotmail.com
    Fixes: 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots")
    Link: https://syzkaller.appspot.com/bug?extid=3030e17bd57a73d39bd7
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Tested-by: syzbot+3030e17bd57a73d39bd7@syzkaller.appspotmail.com
    Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dfc86bea8dc6131c2f2b0cdcf4c97269fcfe653
Author: ChenXiaoSong <chenxiaosong2@huawei.com>
Date:   Wed Nov 16 22:23:53 2022 +0800

    btrfs: add might_sleep() annotations
    
    [ Upstream commit a4c853af0c511d7e0f7cb306bbc8a4f1dbdb64ca ]
    
    Add annotations to functions that might sleep due to allocations or IO
    and could be called from various contexts. In case of btrfs_search_slot
    it's not obvious why it would sleep:
    
        btrfs_search_slot
          setup_nodes_for_search
            reada_for_balance
              btrfs_readahead_node_child
                btrfs_readahead_tree_block
                  btrfs_find_create_tree_block
                    alloc_extent_buffer
                      kmem_cache_zalloc
                        /* allocate memory non-atomically, might sleep */
                        kmem_cache_alloc(GFP_NOFS|__GFP_NOFAIL|__GFP_ZERO)
                  read_extent_buffer_pages
                    submit_extent_page
                      /* disk IO, might sleep */
                      submit_one_bio
    
    Other examples where the sleeping could happen is in 3 places might
    sleep in update_qgroup_limit_item(), as shown below:
    
      update_qgroup_limit_item
        btrfs_alloc_path
          /* allocate memory non-atomically, might sleep */
          kmem_cache_zalloc(btrfs_path_cachep, GFP_NOFS)
    
    Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: 3ed51857a50f ("btrfs: add a sanity check for btrfs root in btrfs_search_slot()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dcbcd9c88e3405e8bfb66206c84acb25cc592d31
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Nov 15 15:46:13 2024 +0000

    btrfs: don't loop for nowait writes when checking for cross references
    
    [ Upstream commit ed67f2a913a4f0fc505db29805c41dd07d3cb356 ]
    
    When checking for delayed refs when verifying if there are cross
    references for a data extent, we stop if the path has nowait set and we
    can't try lock the delayed ref head's mutex, returning -EAGAIN with the
    goal of making a write fallback to a blocking context. However we ignore
    the -EAGAIN at btrfs_cross_ref_exist() when check_delayed_ref() returns
    it, and keep looping instead of immediately returning the -EAGAIN to the
    caller.
    
    Fix this by not looping if we get -EAGAIN and we have a nowait path.
    
    Fixes: 26ce91144631 ("btrfs: make can_nocow_extent nowait compatible")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e6ff207cd5bd924ad94cd1a7c633bcdac0ba1cb
Author: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Date:   Thu Nov 21 18:08:54 2024 +0530

    quota: flush quota_release_work upon quota writeback
    
    [ Upstream commit ac6f420291b3fee1113f21d612fa88b628afab5b ]
    
    One of the paths quota writeback is called from is:
    
    freeze_super()
      sync_filesystem()
        ext4_sync_fs()
          dquot_writeback_dquots()
    
    Since we currently don't always flush the quota_release_work queue in
    this path, we can end up with the following race:
    
     1. dquot are added to releasing_dquots list during regular operations.
     2. FS Freeze starts, however, this does not flush the quota_release_work queue.
     3. Freeze completes.
     4. Kernel eventually tries to flush the workqueue while FS is frozen which
        hits a WARN_ON since transaction gets started during frozen state:
    
      ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)
      __ext4_journal_start_sb+0x64/0x1c0 [ext4]
      ext4_release_dquot+0x90/0x1d0 [ext4]
      quota_release_workfn+0x43c/0x4d0
    
    Which is the following line:
    
      WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);
    
    Which ultimately results in generic/390 failing due to dmesg
    noise. This was detected on powerpc machine 15 cores.
    
    To avoid this, make sure to flush the workqueue during
    dquot_writeback_dquots() so we dont have any pending workitems after
    freeze.
    
    Reported-by: Disha Goel <disgoel@linux.ibm.com>
    CC: stable@vger.kernel.org
    Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    Reviewed-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://patch.msgid.link/20241121123855.645335-2-ojaswin@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5803e3bb941713b17a9b5f15136b3d47f118573
Author: Long Li <leo.lilong@huawei.com>
Date:   Wed Nov 13 17:17:15 2024 +0800

    xfs: remove unknown compat feature check in superblock write validation
    
    [ Upstream commit 652f03db897ba24f9c4b269e254ccc6cc01ff1b7 ]
    
    Compat features are new features that older kernels can safely ignore,
    allowing read-write mounts without issues. The current sb write validation
    implementation returns -EFSCORRUPTED for unknown compat features,
    preventing filesystem write operations and contradicting the feature's
    definition.
    
    Additionally, if the mounted image is unclean, the log recovery may need
    to write to the superblock. Returning an error for unknown compat features
    during sb write validation can cause mount failures.
    
    Although XFS currently does not use compat feature flags, this issue
    affects current kernels' ability to mount images that may use compat
    feature flags in the future.
    
    Since superblock read validation already warns about unknown compat
    features, it's unnecessary to repeat this warning during write validation.
    Therefore, the relevant code in write validation is being removed.
    
    Fixes: 9e037cb7972f ("xfs: check for unknown v5 feature bits in superblock write verifier")
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Long Li <leo.lilong@huawei.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Carlos Maiolino <cem@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c43df7dae28fb9fce96ef088250c1e3c3a77c527
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Oct 23 11:41:59 2024 +0300

    sh: intc: Fix use-after-free bug in register_intc_controller()
    
    [ Upstream commit 63e72e551942642c48456a4134975136cdcb9b3c ]
    
    In the error handling for this function, d is freed without ever
    removing it from intc_list which would lead to a use after free.
    To fix this, let's only add it to the list after everything has
    succeeded.
    
    Fixes: 2dcec7a988a1 ("sh: intc: set_irq_wake() support")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87a95ee34a48dfad198a2002e4966e1d63d53f2b
Author: Liu Jian <liujian56@huawei.com>
Date:   Fri Nov 15 17:38:04 2024 +0800

    sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
    
    [ Upstream commit 4db9ad82a6c823094da27de4825af693a3475d51 ]
    
    Since transport->sock has been set to NULL during reset transport,
    XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the
    xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()
    to dereference the transport->sock that has been set to NULL.
    
    Fixes: 7196dbb02ea0 ("SUNRPC: Allow changing of the TCP timeout parameters on the fly")
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f29fd2cd33e89097f6e5a24e4d85264c89d1966
Author: Li Lingfeng <lilingfeng3@huawei.com>
Date:   Thu Nov 14 12:53:03 2024 +0800

    nfs: ignore SB_RDONLY when mounting nfs
    
    [ Upstream commit 52cb7f8f177878b4f22397b9c4d2c8f743766be3 ]
    
    When exporting only one file system with fsid=0 on the server side, the
    client alternately uses the ro/rw mount options to perform the mount
    operation, and a new vfsmount is generated each time.
    
    It can be reproduced as follows:
    [root@localhost ~]# mount /dev/sda /mnt2
    [root@localhost ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)" >/etc/exports
    [root@localhost ~]# systemctl restart nfs-server
    [root@localhost ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
    [root@localhost ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
    [root@localhost ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa
    [root@localhost ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa
    [root@localhost ~]# mount | grep nfs4
    127.0.0.1:/ on /mnt/sdaa type nfs4 (ro,relatime,vers=4.2,rsize=1048576,...
    127.0.0.1:/ on /mnt/sdaa type nfs4 (rw,relatime,vers=4.2,rsize=1048576,...
    127.0.0.1:/ on /mnt/sdaa type nfs4 (ro,relatime,vers=4.2,rsize=1048576,...
    127.0.0.1:/ on /mnt/sdaa type nfs4 (rw,relatime,vers=4.2,rsize=1048576,...
    [root@localhost ~]#
    
    We expected that after mounting with the ro option, using the rw option to
    mount again would return EBUSY, but the actual situation was not the case.
    
    As shown above, when mounting for the first time, a superblock with the ro
    flag will be generated, and at the same time, in do_new_mount_fc -->
    do_add_mount, it detects that the superblock corresponding to the current
    target directory is inconsistent with the currently generated one
    (path->mnt->mnt_sb != newmnt->mnt.mnt_sb), and a new vfsmount will be
    generated.
    
    When mounting with the rw option for the second time, since no matching
    superblock can be found in the fs_supers list, a new superblock with the
    rw flag will be generated again. The superblock in use (ro) is different
    from the newly generated superblock (rw), and a new vfsmount will be
    generated again.
    
    When mounting with the ro option for the third time, the superblock (ro)
    is found in fs_supers, the superblock in use (rw) is different from the
    found superblock (ro), and a new vfsmount will be generated again.
    
    We can switch between ro/rw through remount, and only one superblock needs
    to be generated, thus avoiding the problem of repeated generation of
    vfsmount caused by switching superblocks.
    
    Furthermore, This can also resolve the issue described in the link.
    
    Fixes: 275a5d24bf56 ("NFS: Error when mounting the same filesystem with different options")
    Link: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2f866533860c8a4775666ec53090cca7b9d4634
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Nov 20 08:56:39 2024 +0900

    modpost: remove incorrect code in do_eisa_entry()
    
    [ Upstream commit 0c3e091319e4748cb36ac9a50848903dc6f54054 ]
    
    This function contains multiple bugs after the following commits:
    
     - ac551828993e ("modpost: i2c aliases need no trailing wildcard")
     - 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling")
    
    Commit ac551828993e inserted the following code to do_eisa_entry():
    
        else
                strcat(alias, "*");
    
    This is incorrect because 'alias' is uninitialized. If it is not
    NULL-terminated, strcat() could cause a buffer overrun.
    
    Even if 'alias' happens to be zero-filled, it would output:
    
        MODULE_ALIAS("*");
    
    This would match anything. As a result, the module could be loaded by
    any unrelated uevent from an unrelated subsystem.
    
    Commit ac551828993e introduced another bug.            
    
    Prior to that commit, the conditional check was:
    
        if (eisa->sig[0])
    
    This checked if the first character of eisa_device_id::sig was not '\0'.
    
    However, commit ac551828993e changed it as follows:
    
        if (sig[0])
    
    sig[0] is NOT the first character of the eisa_device_id::sig. The
    type of 'sig' is 'char (*)[8]', meaning that the type of 'sig[0]' is
    'char [8]' instead of 'char'. 'sig[0]' and 'symval' refer to the same
    address, which never becomes NULL.
    
    The correct conversion would have been:
    
        if ((*sig)[0])
    
    However, this if-conditional was meaningless because the earlier change
    in commit ac551828993e was incorrect.
    
    This commit removes the entire incorrect code, which should never have
    been executed.
    
    Fixes: ac551828993e ("modpost: i2c aliases need no trailing wildcard")
    Fixes: 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6f772c7963f84461e551b45cc1a64fa5bb8fe60
Author: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date:   Fri Nov 22 11:10:30 2024 +0100

    rtc: ab-eoz9: don't fail temperature reads on undervoltage notification
    
    [ Upstream commit e0779a0dcf41a6452ac0a169cd96863feb5787c7 ]
    
    The undervoltage flags reported by the RTC are useful to know if the
    time and date are reliable after a reboot. Although the threshold VLOW1
    indicates that the thermometer has been shutdown and time compensation
    is off, it doesn't mean that the temperature readout is currently
    impossible.
    
    As the system is running, the RTC voltage is now fully established and
    we can read the temperature.
    
    Fixes: 67075b63cce2 ("rtc: add AB-RTCMC-32.768kHz-EOZ9 RTC support")
    Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Link: https://lore.kernel.org/r/20241122101031.68916-3-maxime.chevallier@bootlin.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4dcaa86552dc253b752deac4473dcdf556ea6871
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Wed Nov 20 16:13:34 2024 -0800

    perf/arm-cmn: Ensure port and device id bits are set properly
    
    [ Upstream commit dfdf714fed559c09021df1d2a4bb64c0ad5f53bc ]
    
    The portid_bits and deviceid_bits were set only for XP type nodes in
    the arm_cmn_discover() and it confused other nodes to find XP nodes.
    Copy the both bits from the XP nodes directly when it sets up a new
    node.
    
    Fixes: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20241121001334.331334-1-namhyung@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddce811ed3a466bd96fee9c3d00bc438b8dd0f31
Author: Chun-Tse Shao <ctshao@google.com>
Date:   Fri Nov 8 05:08:05 2024 +0000

    perf/arm-smmuv3: Fix lockdep assert in ->event_init()
    
    [ Upstream commit 02a55f2743012a8089f09f6867220c3d57f16564 ]
    
    Same as
    https://lore.kernel.org/all/20240514180050.182454-1-namhyung@kernel.org/,
    we should skip `for_each_sibling_event()` for group leader since it
    doesn't have the ctx yet.
    
    Fixes: f3c0eba28704 ("perf: Add a few assertions")
    Reported-by: Greg Thelen <gthelen@google.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Tuan Phan <tuanphan@os.amperecomputing.com>
    Signed-off-by: Chun-Tse Shao <ctshao@google.com>
    Acked-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20241108050806.3730811-1-ctshao@google.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9e26059664bd9ebc64a0e8f5216266fc9f84265
Author: Alex Zenla <alex@edera.dev>
Date:   Thu Nov 21 22:51:00 2024 +0000

    9p/xen: fix release of IRQ
    
    [ Upstream commit e43c608f40c065b30964f0a806348062991b802d ]
    
    Kernel logs indicate an IRQ was double-freed.
    
    Pass correct device ID during IRQ release.
    
    Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend")
    Signed-off-by: Alex Zenla <alex@edera.dev>
    Signed-off-by: Alexander Merritt <alexander@edera.dev>
    Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Message-ID: <20241121225100.5736-1-alexander@edera.dev>
    [Dominique: remove confusing variable reset to 0]
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91b4763da3ee6ef69c93ec60f52d8ffca0198a76
Author: Alex Zenla <alex@edera.dev>
Date:   Tue Nov 19 21:16:33 2024 +0000

    9p/xen: fix init sequence
    
    [ Upstream commit 7ef3ae82a6ebbf4750967d1ce43bcdb7e44ff74b ]
    
    Large amount of mount hangs observed during hotplugging of 9pfs devices. The
    9pfs Xen driver attempts to initialize itself more than once, causing the
    frontend and backend to disagree: the backend listens on a channel that the
    frontend does not send on, resulting in stalled processing.
    
    Only allow initialization of 9p frontend once.
    
    Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence")
    Signed-off-by: Alex Zenla <alex@edera.dev>
    Signed-off-by: Alexander Merritt <alexander@edera.dev>
    Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Message-ID: <20241119211633.38321-1-alexander@edera.dev>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c375804cf59e0c1c9caa5e15d1093886a72352f1
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Nov 19 08:26:02 2024 +0100

    block: return unsigned int from bdev_io_min
    
    [ Upstream commit 46fd48ab3ea3eb3bb215684bd66ea3d260b091a9 ]
    
    The underlying limit is defined as an unsigned int, so return that from
    bdev_io_min as well.
    
    Fixes: ac481c20ef8f ("block: Topology ioctls")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: John Garry <john.g.garry@oracle.com>
    Link: https://lore.kernel.org/r/20241119072602.1059488-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfc4647055ee0f4ca0c61553d119e5ada630bce1
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Nov 13 12:30:32 2024 +0100

    rtc: rzn1: fix BCD to rtc_time conversion errors
    
    [ Upstream commit 55727188dfa3572aecd946e58fab9e4a64f06894 ]
    
    tm_mon describes months from 0 to 11, but the register contains BCD from
    1 to 12. tm_year contains years since 1900, but the BCD contains 20XX.
    Apply the offsets when converting these numbers.
    
    Fixes: deeb4b5393e1 ("rtc: rzn1: Add new RTC driver")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20241113113032.27409-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37a22fd4b815e3f1d2570f8b11bf44566292c7d6
Author: Qingfang Deng <qingfang.deng@siflower.com.cn>
Date:   Mon Jul 1 12:52:05 2024 +0800

    jffs2: fix use of uninitialized variable
    
    [ Upstream commit 3ba44ee966bc3c41dd8a944f963466c8fcc60dc8 ]
    
    When building the kernel with -Wmaybe-uninitialized, the compiler
    reports this warning:
    
    In function 'jffs2_mark_erased_block',
        inlined from 'jffs2_erase_pending_blocks' at fs/jffs2/erase.c:116:4:
    fs/jffs2/erase.c:474:9: warning: 'bad_offset' may be used uninitialized [-Wmaybe-uninitialized]
      474 |         jffs2_erase_failed(c, jeb, bad_offset);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    fs/jffs2/erase.c: In function 'jffs2_erase_pending_blocks':
    fs/jffs2/erase.c:402:18: note: 'bad_offset' was declared here
      402 |         uint32_t bad_offset;
          |                  ^~~~~~~~~~
    
    When mtd->point() is used, jffs2_erase_pending_blocks can return -EIO
    without initializing bad_offset, which is later used at the filebad
    label in jffs2_mark_erased_block.
    Fix it by initializing this variable.
    
    Fixes: 8a0f572397ca ("[JFFS2] Return values of jffs2_block_check_erase error paths")
    Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74981f7577d183acad1cd58f74c10d263711a215
Author: Waqar Hameed <waqar.hameed@axis.com>
Date:   Wed Oct 9 16:46:59 2024 +0200

    ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit
    
    [ Upstream commit 4617fb8fc15effe8eda4dd898d4e33eb537a7140 ]
    
    After an insertion in TNC, the tree might split and cause a node to
    change its `znode->parent`. A further deletion of other nodes in the
    tree (which also could free the nodes), the aforementioned node's
    `znode->cparent` could still point to a freed node. This
    `znode->cparent` may not be updated when getting nodes to commit in
    `ubifs_tnc_start_commit()`. This could then trigger a use-after-free
    when accessing the `znode->cparent` in `write_index()` in
    `ubifs_tnc_end_commit()`.
    
    This can be triggered by running
    
      rm -f /etc/test-file.bin
      dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync
    
    in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then
    reports:
    
      BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950
      Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153
    
      Call trace:
       dump_backtrace+0x0/0x340
       show_stack+0x18/0x24
       dump_stack_lvl+0x9c/0xbc
       print_address_description.constprop.0+0x74/0x2b0
       kasan_report+0x1d8/0x1f0
       kasan_check_range+0xf8/0x1a0
       memcpy+0x84/0xf4
       ubifs_tnc_end_commit+0xa5c/0x1950
       do_commit+0x4e0/0x1340
       ubifs_bg_thread+0x234/0x2e0
       kthread+0x36c/0x410
       ret_from_fork+0x10/0x20
    
      Allocated by task 401:
       kasan_save_stack+0x38/0x70
       __kasan_kmalloc+0x8c/0xd0
       __kmalloc+0x34c/0x5bc
       tnc_insert+0x140/0x16a4
       ubifs_tnc_add+0x370/0x52c
       ubifs_jnl_write_data+0x5d8/0x870
       do_writepage+0x36c/0x510
       ubifs_writepage+0x190/0x4dc
       __writepage+0x58/0x154
       write_cache_pages+0x394/0x830
       do_writepages+0x1f0/0x5b0
       filemap_fdatawrite_wbc+0x170/0x25c
       file_write_and_wait_range+0x140/0x190
       ubifs_fsync+0xe8/0x290
       vfs_fsync_range+0xc0/0x1e4
       do_fsync+0x40/0x90
       __arm64_sys_fsync+0x34/0x50
       invoke_syscall.constprop.0+0xa8/0x260
       do_el0_svc+0xc8/0x1f0
       el0_svc+0x34/0x70
       el0t_64_sync_handler+0x108/0x114
       el0t_64_sync+0x1a4/0x1a8
    
      Freed by task 403:
       kasan_save_stack+0x38/0x70
       kasan_set_track+0x28/0x40
       kasan_set_free_info+0x28/0x4c
       __kasan_slab_free+0xd4/0x13c
       kfree+0xc4/0x3a0
       tnc_delete+0x3f4/0xe40
       ubifs_tnc_remove_range+0x368/0x73c
       ubifs_tnc_remove_ino+0x29c/0x2e0
       ubifs_jnl_delete_inode+0x150/0x260
       ubifs_evict_inode+0x1d4/0x2e4
       evict+0x1c8/0x450
       iput+0x2a0/0x3c4
       do_unlinkat+0x2cc/0x490
       __arm64_sys_unlinkat+0x90/0x100
       invoke_syscall.constprop.0+0xa8/0x260
       do_el0_svc+0xc8/0x1f0
       el0_svc+0x34/0x70
       el0t_64_sync_handler+0x108/0x114
       el0t_64_sync+0x1a4/0x1a8
    
    The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free
    when a node becomes root in TNC but still has a `cparent` to an already
    freed node. More specifically, consider the following TNC:
    
             zroot
             /
            /
          zp1
          /
         /
        zn
    
    Inserting a new node `zn_new` with a key smaller then `zn` will trigger
    a split in `tnc_insert()` if `zp1` is full:
    
             zroot
             /   \
            /     \
          zp1     zp2
          /         \
         /           \
      zn_new          zn
    
    `zn->parent` has now been moved to `zp2`, *but* `zn->cparent` still
    points to `zp1`.
    
    Now, consider a removal of all the nodes _except_ `zn`. Just when
    `tnc_delete()` is about to delete `zroot` and `zp2`:
    
             zroot
                 \
                  \
                  zp2
                    \
                     \
                     zn
    
    `zroot` and `zp2` get freed and the tree collapses:
    
               zn
    
    `zn` now becomes the new `zroot`.
    
    `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and
    `write_index()` will check its `znode->cparent` that wrongly points to
    the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called
    with `znode->cparent->zbranch[znode->iip].hash` that triggers the
    use-after-free!
    
    Fix this by explicitly setting `znode->cparent` to `NULL` in
    `get_znodes_to_commit()` for the root node. The search for the dirty
    nodes is bottom-up in the tree. Thus, when `find_next_dirty(znode)`
    returns NULL, the current `znode` _is_ the root node. Add an assert for
    this.
    
    Fixes: 16a26b20d2af ("ubifs: authentication: Add hashes to index nodes")
    Tested-by: Waqar Hameed <waqar.hameed@axis.com>
    Co-developed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6afdcb285794e75d2c8995e3a44f523c176cc2de
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Oct 11 12:50:02 2024 +0800

    ubi: fastmap: Fix duplicate slab cache names while attaching
    
    [ Upstream commit bcddf52b7a17adcebc768d26f4e27cf79adb424c ]
    
    Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when
    DEBUG_VM=y"), the duplicate slab cache names can be detected and a
    kernel WARNING is thrown out.
    In UBI fast attaching process, alloc_ai() could be invoked twice
    with the same slab cache name 'ubi_aeb_slab_cache', which will trigger
    following warning messages:
     kmem_cache of name 'ubi_aeb_slab_cache' already exists
     WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107
              __kmem_cache_create_args+0x100/0x5f0
     Modules linked in: ubi(+) nandsim [last unloaded: nandsim]
     CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2
     RIP: 0010:__kmem_cache_create_args+0x100/0x5f0
     Call Trace:
       __kmem_cache_create_args+0x100/0x5f0
       alloc_ai+0x295/0x3f0 [ubi]
       ubi_attach+0x3c3/0xcc0 [ubi]
       ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]
       ubi_init+0x3fb/0x800 [ubi]
       do_init_module+0x265/0x7d0
       __x64_sys_finit_module+0x7a/0xc0
    
    The problem could be easily reproduced by loading UBI device by fastmap
    with CONFIG_DEBUG_VM=y.
    Fix it by using different slab names for alloc_ai() callers.
    
    Fixes: d2158f69a7d4 ("UBI: Remove alloc_ai() slab name from parameter list")
    Fixes: fdf10ed710c0 ("ubi: Rework Fastmap attach base code")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f88a7f5e261fd8aee3edbdcf083424a81672cdc5
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Thu Sep 5 09:09:09 2024 +0800

    ubifs: Correct the total block count by deducting journal reservation
    
    [ Upstream commit 84a2bee9c49769310efa19601157ef50a1df1267 ]
    
    Since commit e874dcde1cbf ("ubifs: Reserve one leb for each journal
    head while doing budget"), available space is calulated by deducting
    reservation for all journal heads. However, the total block count (
    which is only used by statfs) is not updated yet, which will cause
    the wrong displaying for used space(total - available).
    Fix it by deducting reservation for all journal heads from total
    block count.
    
    Fixes: e874dcde1cbf ("ubifs: Reserve one leb for each journal head while doing budget")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6aa2932c6e6a7fb2a7daeddd64f1201c6156a3f1
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Aug 19 11:26:22 2024 +0800

    ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty
    
    [ Upstream commit c4595fe394a289927077e3da561db27811919ee0 ]
    
    Since commit 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb
    before wear leveling"), wear_leveling_worker() won't schedule fm_work
    if wear-leveling pool is empty, which could temporarily disable the
    wear-leveling until the fastmap is updated(eg. pool becomes empty).
    Fix it by scheduling fm_work if wl_pool is empty during wear-leveing.
    
    Fixes: 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb before wear leveling")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fde56535505dde3336df438e949ef4742b6d6d6e
Author: Yongliang Gao <leonylgao@tencent.com>
Date:   Fri Oct 11 12:31:53 2024 +0800

    rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
    
    [ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ]
    
    If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
    uninitialized data, or an illegal date/time read from the RTC hardware.
    
    When calling rtc_tm_to_ktime later, the result may be a very large value
    (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,
    they will continually expire, may causing kernel softlockup.
    
    Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events")
    Signed-off-by: Yongliang Gao <leonylgao@tencent.com>
    Acked-by: Jingqun Li <jingqunli@tencent.com>
    Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54a60de9a64ae096021a4c4cf61365b70f6aae85
Author: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Date:   Tue Oct 8 13:17:37 2024 +0900

    rtc: abx80x: Fix WDT bit position of the status register
    
    [ Upstream commit 10e078b273ee7a2b8b4f05a64ac458f5e652d18d ]
    
    The WDT bit in the status register is 5, not 6. This fixes from 6 to 5.
    
    Link: https://abracon.com/Support/AppsManuals/Precisiontiming/AB08XX-Application-Manual.pdf
    Link: https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-1805-C3_App-Manual.pdf
    Fixes: 749e36d0a0d7 ("rtc: abx80x: add basic watchdog support")
    Cc: Jeremy Gebben <jgebben@sweptlaser.com>
    Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
    Link: https://lore.kernel.org/r/20241008041737.1640633-1-iwamatsu@nigauri.org
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba3135792e399cb92d6fb3f59119ec66e228b33b
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 11:37:27 2024 +0800

    rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit b6cd7adec0cf03f0aefc55676e71dd721cbc71a8 ]
    
    If request_irq() fails in st_rtc_probe(), there is no need to enable
    the irq, and if it succeeds, disable_irq() after request_irq() still has
    a time gap in which interrupts can come.
    
    request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when
    request IRQ.
    
    Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20240912033727.3013951-1-ruanjinjie@huawei.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba6e6c04f60fe52d91520ac4d749d372d4c74521
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Nov 8 12:13:31 2024 -0500

    NFSv4.0: Fix a use-after-free problem in the asynchronous open()
    
    [ Upstream commit 2fdb05dc0931250574f0cb0ebeb5ed8e20f4a889 ]
    
    Yang Erkun reports that when two threads are opening files at the same
    time, and are forced to abort before a reply is seen, then the call to
    nfs_release_seqid() in nfs4_opendata_free() can result in a
    use-after-free of the pointer to the defunct rpc task of the other
    thread.
    The fix is to ensure that if the RPC call is aborted before the call to
    nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()
    in nfs4_open_release() before the rpc_task is freed.
    
    Reported-by: Yang Erkun <yangerkun@huawei.com>
    Fixes: 24ac23ab88df ("NFSv4: Convert open() into an asynchronous RPC call")
    Reviewed-by: Yang Erkun <yangerkun@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a73401dacf0d93febadc2e1457fae2f9e2b066f
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Wed Nov 6 18:39:33 2024 +0800

    um: Always dump trace for specified task in show_stack
    
    [ Upstream commit 0f659ff362eac69777c4c191b7e5ccb19d76c67d ]
    
    Currently, show_stack() always dumps the trace of the current task.
    However, it should dump the trace of the specified task if one is
    provided. Otherwise, things like running "echo t > sysrq-trigger"
    won't work as expected.
    
    Fixes: 970e51feaddb ("um: Add support for CONFIG_STACKTRACE")
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Link: https://patch.msgid.link/20241106103933.1132365-1-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fd508d43354440f5ca3446d6887771c82d79bf0
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Fri Sep 13 10:33:02 2024 +0800

    um: Fix the return value of elf_core_copy_task_fpregs
    
    [ Upstream commit 865e3845eeaa21e9a62abc1361644e67124f1ec0 ]
    
    This function is expected to return a boolean value, which should be
    true on success and false on failure.
    
    Fixes: d1254b12c93e ("uml: fix x86_64 core dump crash")
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Link: https://patch.msgid.link/20240913023302.130300-1-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1575df968650d11771359e5ac78278c5b0cc19f3
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Mon Sep 16 12:59:48 2024 +0800

    um: Fix potential integer overflow during physmem setup
    
    [ Upstream commit a98b7761f697e590ed5d610d87fa12be66f23419 ]
    
    This issue happens when the real map size is greater than LONG_MAX,
    which can be easily triggered on UML/i386.
    
    Fixes: fe205bdd1321 ("um: Print minimum physical memory requirement")
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Link: https://patch.msgid.link/20240916045950.508910-3-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 068c0b50f3f700b94f78850834cd91ae3b34c2c1
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Mon Oct 21 22:23:42 2024 +0800

    SUNRPC: make sure cache entry active before cache_show
    
    commit 2862eee078a4d2d1f584e7f24fa50dddfa5f3471 upstream.
    
    The function `c_show` was called with protection from RCU. This only
    ensures that `cp` will not be freed. Therefore, the reference count for
    `cp` can drop to zero, which will trigger a refcount use-after-free
    warning when `cache_get` is called. To resolve this issue, use
    `cache_get_rcu` to ensure that `cp` remains active.
    
    ------------[ cut here ]------------
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 7 PID: 822 at lib/refcount.c:25
    refcount_warn_saturate+0xb1/0x120
    CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.16.1-2.fc37 04/01/2014
    RIP: 0010:refcount_warn_saturate+0xb1/0x120
    
    Call Trace:
     <TASK>
     c_show+0x2fc/0x380 [sunrpc]
     seq_read_iter+0x589/0x770
     seq_read+0x1e5/0x270
     proc_reg_read+0xe1/0x140
     vfs_read+0x125/0x530
     ksys_read+0xc1/0x160
     do_syscall_64+0x5f/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Cc: stable@vger.kernel.org # v4.20+
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de53c5305184ca1333b87e695d329d1502d694ce
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Sep 17 12:15:23 2024 -0400

    NFSD: Prevent a potential integer overflow
    
    commit 7f33b92e5b18e904a481e6e208486da43e4dc841 upstream.
    
    If the tag length is >= U32_MAX - 3 then the "length + 4" addition
    can result in an integer overflow. Address this by splitting the
    decoding into several steps so that decode_cb_compound4res() does
    not have to perform arithmetic on the unsafe length value.
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d230cfd4b9b0558c7b2039ba1def2ce6b6cd158
Author: Ma Wupeng <mawupeng1@huawei.com>
Date:   Wed Oct 23 17:31:29 2024 +0800

    ipc: fix memleak if msg_init_ns failed in create_ipc_ns
    
    commit bc8f5921cd69188627c08041276238de222ab466 upstream.
    
    Percpu memory allocation may failed during create_ipc_ns however this
    fail is not handled properly since ipc sysctls and mq sysctls is not
    released properly. Fix this by release these two resource when failure.
    
    Here is the kmemleak stack when percpu failed:
    
    unreferenced object 0xffff88819de2a600 (size 512):
      comm "shmem_2nstest", pid 120711, jiffies 4300542254
      hex dump (first 32 bytes):
        60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff  `.........H.....
        04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff  ........ .V.....
      backtrace (crc be7cba35):
        [<ffffffff81b43f83>] __kmalloc_node_track_caller_noprof+0x333/0x420
        [<ffffffff81a52e56>] kmemdup_noprof+0x26/0x50
        [<ffffffff821b2f37>] setup_mq_sysctls+0x57/0x1d0
        [<ffffffff821b29cc>] copy_ipcs+0x29c/0x3b0
        [<ffffffff815d6a10>] create_new_namespaces+0x1d0/0x920
        [<ffffffff815d7449>] copy_namespaces+0x2e9/0x3e0
        [<ffffffff815458f3>] copy_process+0x29f3/0x7ff0
        [<ffffffff8154b080>] kernel_clone+0xc0/0x650
        [<ffffffff8154b6b1>] __do_sys_clone+0xa1/0xe0
        [<ffffffff843df8ff>] do_syscall_64+0xbf/0x1c0
        [<ffffffff846000b0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    Link: https://lkml.kernel.org/r/20241023093129.3074301-1-mawupeng1@huawei.com
    Fixes: 72d1e611082e ("ipc/msg: mitigate the lock contention with percpu counter")
    Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f34d90a7febbb3a29bb2d2d05529b89833d82d2
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Fri Nov 1 21:54:53 2024 +0100

    lib: string_helpers: silence snprintf() output truncation warning
    
    commit a508ef4b1dcc82227edc594ffae583874dd425d7 upstream.
    
    The output of ".%03u" with the unsigned int in range [0, 4294966295] may
    get truncated if the target buffer is not 12 bytes. This can't really
    happen here as the 'remainder' variable cannot exceed 999 but the
    compiler doesn't know it. To make it happy just increase the buffer to
    where the warning goes away.
    
    Fixes: 3c9f3681d0b4 ("[SCSI] lib: add generic helper to print sizes rounded to the correct SI range")
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Kees Cook <kees@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: https://lore.kernel.org/r/20241101205453.9353-1-brgl@bgdev.pl
    Signed-off-by: Kees Cook <kees@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2de63befbea88b41124f2f8f2c41961d353023bd
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Nov 19 11:06:46 2024 +0800

    ublk: fix error code for unsupported command
    
    commit 34c1227035b3ab930a1ae6ab6f22fec1af8ab09e upstream.
    
    ENOTSUPP is for kernel use only, and shouldn't be sent to userspace.
    
    Fix it by replacing it with EOPNOTSUPP.
    
    Cc: stable@vger.kernel.org
    Fixes: bfbcef036396 ("ublk_drv: move ublk_get_device_from_id into ublk_ctrl_uring_cmd")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20241119030646.2319030-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9e72352a10ae89a430449f7bfeb043e75c255d9
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Nov 14 01:02:18 2024 +0000

    usb: dwc3: gadget: Fix looping of queued SG entries
    
    commit b7fc65f5141c24785dc8c19249ca4efcf71b3524 upstream.
    
    The dwc3_request->num_queued_sgs is decremented on completion. If a
    partially completed request is handled, then the
    dwc3_request->num_queued_sgs no longer reflects the total number of
    num_queued_sgs (it would be cleared).
    
    Correctly check the number of request SG entries remained to be prepare
    and queued. Failure to do this may cause null pointer dereference when
    accessing non-existent SG entry.
    
    Cc: stable@vger.kernel.org
    Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/d07a7c4aa0fcf746cdca0515150dbe5c52000af7.1731545781.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cb33da1c8dd958e1c48ec4dce70538e08d47eda
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Nov 14 01:02:12 2024 +0000

    usb: dwc3: gadget: Fix checking for number of TRBs left
    
    commit 02a6982b0ccfcdc39e20016f5fc9a1b7826a6ee7 upstream.
    
    The check whether the TRB ring is full or empty in dwc3_calc_trbs_left()
    is insufficient. It assumes there are active TRBs if there's any request
    in the started_list. However, that's not the case for requests with a
    large SG list.
    
    That is, if we have a single usb request that requires more TRBs than
    the total TRBs in the TRB ring, the queued TRBs will be available when
    all the TRBs in the ring are completed. But the request is only
    partially completed and remains in the started_list. With the current
    logic, the TRB ring is empty, but dwc3_calc_trbs_left() returns 0.
    
    Fix this by additionally checking for the request->num_trbs for active
    TRB count.
    
    Cc: stable@vger.kernel.org
    Fixes: 51f1954ad853 ("usb: dwc3: gadget: Fix dwc3_calc_trbs_left()")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/708dc62b56b77da1f704cc2ae9b6ddb1f2dbef1f.1731545781.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c749500b28cae67410792096133ee7f282439c51
Author: Hubert Wiśniewski <hubert.wisniewski.25632@gmail.com>
Date:   Sun Nov 10 18:21:48 2024 +0100

    usb: musb: Fix hardware lockup on first Rx endpoint request
    
    commit 3fc137386c4620305bbc2a216868c53f9245670a upstream.
    
    There is a possibility that a request's callback could be invoked from
    usb_ep_queue() (call trace below, supplemented with missing calls):
    
    req->complete from usb_gadget_giveback_request
            (drivers/usb/gadget/udc/core.c:999)
    usb_gadget_giveback_request from musb_g_giveback
            (drivers/usb/musb/musb_gadget.c:147)
    musb_g_giveback from rxstate
            (drivers/usb/musb/musb_gadget.c:784)
    rxstate from musb_ep_restart
            (drivers/usb/musb/musb_gadget.c:1169)
    musb_ep_restart from musb_ep_restart_resume_work
            (drivers/usb/musb/musb_gadget.c:1176)
    musb_ep_restart_resume_work from musb_queue_resume_work
            (drivers/usb/musb/musb_core.c:2279)
    musb_queue_resume_work from musb_gadget_queue
            (drivers/usb/musb/musb_gadget.c:1241)
    musb_gadget_queue from usb_ep_queue
            (drivers/usb/gadget/udc/core.c:300)
    
    According to the docstring of usb_ep_queue(), this should not happen:
    
    "Note that @req's ->complete() callback must never be called from within
    usb_ep_queue() as that can create deadlock situations."
    
    In fact, a hardware lockup might occur in the following sequence:
    
    1. The gadget is initialized using musb_gadget_enable().
    2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an
       interrupt.
    3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an
       empty queue (next_request() returns NULL). The interrupt flag has
       already been cleared by the glue layer handler, but the RXPKTRDY flag
       remains set.
    4. The first request is enqueued using usb_ep_queue(), leading to the call
       of req->complete(), as shown in the call trace above.
    5. If the callback enables IRQs and another packet is waiting, step (3)
       repeats. The request queue is empty because usb_g_giveback() removes the
       request before invoking the callback.
    6. The endpoint remains locked up, as the interrupt triggered by hardware
       setting the RXPKTRDY flag has been handled, but the flag itself remains
       set.
    
    For this scenario to occur, it is only necessary for IRQs to be enabled at
    some point during the complete callback. This happens with the USB Ethernet
    gadget, whose rx_complete() callback calls netif_rx(). If called in the
    task context, netif_rx() disables the bottom halves (BHs). When the BHs are
    re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The
    gadget itself is initialized at module load (or at boot if built-in), but
    the first request is enqueued when the network interface is brought up,
    triggering rx_complete() in the task context via ioctl(). If a packet
    arrives while the interface is down, it can prevent the interface from
    receiving any further packets from the USB host.
    
    The situation is quite complicated with many parties involved. This
    particular issue can be resolved in several possible ways:
    
    1. Ensure that callbacks never enable IRQs. This would be difficult to
       enforce, as discovering how netif_rx() interacts with interrupts was
       already quite challenging and u_ether is not the only function driver.
       Similar "bugs" could be hidden in other drivers as well.
    2. Disable MUSB interrupts in musb_g_giveback() before calling the callback
       and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),
       for example). This would ensure that MUSB interrupts are not handled
       during the callback, even if IRQs are enabled. In fact, it would allow
       IRQs to be enabled when releasing the lock. However, this feels like an
       inelegant hack.
    3. Modify the interrupt handler to clear the RXPKTRDY flag if the request
       queue is empty. While this approach also feels like a hack, it wastes
       CPU time by attempting to handle incoming packets when the software is
       not ready to process them.
    4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().
       This ensures that the hardware can receive packets when there is at
       least one request in the queue. Once IRQs are enabled, the interrupt
       handler will be able to correctly process the next incoming packet
       (eventually calling rxstate()). This approach may cause one or two
       packets to be dropped (two if double buffering is enabled), but this
       seems to be a minor issue, as packet loss can occur when the software is
       not yet ready to process them. Additionally, this solution makes the
       gadget driver compliant with the rule mentioned in the docstring of
       usb_ep_queue().
    
    There may be additional solutions, but from these four, the last one has
    been chosen as it seems to be the most appropriate, as it addresses the
    "bad" behavior of the driver.
    
    Fixes: baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hubert Wiśniewski <hubert.wisniewski.25632@gmail.com>
    Link: https://lore.kernel.org/r/4ee1ead4525f78fb5909a8cbf99513ad0082ad21.camel@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 338ae99f3ee0ababbb8bf9fbff67c30894a557ed
Author: Steve French <stfrench@microsoft.com>
Date:   Mon Nov 18 12:19:46 2024 -0600

    smb3: request handle caching when caching directories
    
    commit 9ed9d83a51a9636d367c796252409e7b2f4de4d4 upstream.
    
    This client was only requesting READ caching, not READ and HANDLE caching
    in the LeaseState on the open requests we send for directories.  To
    delay closing a handle (e.g. for caching directory contents) we should
    be requesting HANDLE as well as READ (as we already do for deferred
    close of files).   See MS-SMB2 3.3.1.4 e.g.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ca7a0a98369116d04d90e4bce157ffc7b2d2971
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 28 08:26:45 2024 +0100

    ALSA: hda/realtek: Apply quirk for Medion E15433
    
    commit ca0f79f0286046f6a91c099dc941cf7afae198d6 upstream.
    
    Medion E15433 laptop wich ALC269VC (SSID 2782:1705) needs the same
    workaround for the missing speaker as another model.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1233298
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241128072646.15659-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d186d6aac7a6088755c775a5c0f6e955e8fd8a2
Author: Dinesh Kumar <desikumar81@gmail.com>
Date:   Mon Nov 25 14:58:42 2024 +0530

    ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max
    
    commit 5ebe792a5139f1ce6e4aed22bef12e7e2660df96 upstream.
    
    Internal Speaker of Infinix Y4 Max remains muted due to incorrect
    Pin configuration, and the Internal Mic records high noise. This patch
    corrects the Pin configuration for the Internal Speaker and limits
    the Internal Mic boost.
    HW Probe for device: https://linux-hardware.org/?probe=6d4386c347
    Test: Internal Speaker works fine, Mic has low noise.
    
    Signed-off-by: Dinesh Kumar <desikumar81@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241125092842.13208-1-desikumar81@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a5fc93296f96d26fa4a3ccd99a5441e516a5247
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Nov 21 16:16:26 2024 +0800

    ALSA: hda/realtek: Set PCBeep to default value for ALC274
    
    commit 155699ccab7c78cbba69798242b68bc8ac66d5d2 upstream.
    
    BIOS Enable PC beep path cause pop noise via speaker during boot time.
    Set to default value from driver will solve the issue.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/2721bb57e20a44c3826c473e933f9105@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe73dc2740acd49148d70a47affe34e20da0810d
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Nov 14 15:08:07 2024 +0800

    ALSA: hda/realtek: Update ALC225 depop procedure
    
    commit 1fd50509fe14a9adc9329e0454b986157a4c155a upstream.
    
    Old procedure has a chance to meet Headphone no output.
    
    Fixes: da911b1f5e98 ("ALSA: hda/realtek - update ALC225 depop optimize")
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/5a27b016ba9d42b4a4e6dadce50a3ba4@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 832efbb74b1578e3737d593a204d42af8bd1b81b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 20 15:11:02 2024 +0100

    ALSA: pcm: Add sanity NULL check for the default mmap fault handler
    
    commit d2913a07d9037fe7aed4b7e680684163eaed6bc4 upstream.
    
    A driver might allow the mmap access before initializing its
    runtime->dma_area properly.  Add a proper NULL check before passing to
    virt_to_page() for avoiding a panic.
    
    Reported-by: syzbot+4bf62a7b1d0f4fdb7ae2@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20241120141104.7060-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71f9c0f1e3414a17544b5a7fb4ef6e8702c9c21f
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Mon Oct 14 16:52:41 2024 +0200

    media: v4l2-core: v4l2-dv-timings: check cvt/gtf result
    
    commit 9f070b1862f3411b8bcdfd51a8eaad25286f9deb upstream.
    
    The v4l2_detect_cvt/gtf functions should check the result against the
    timing capabilities: these functions calculate the timings, so if they
    are out of bounds, they should be rejected.
    
    To do this, add the struct v4l2_dv_timings_cap as argument to those
    functions.
    
    This required updates to the adv7604 and adv7842 drivers since the
    prototype of these functions has now changed. The timings struct
    that is passed to v4l2_detect_cvt/gtf in those two drivers is filled
    with the timings detected by the hardware.
    
    The vivid driver was also updated, but an additional check was added:
    the width and height specified by VIDIOC_S_DV_TIMINGS has to match the
    calculated result, otherwise something went wrong. Note that vivid
    *emulates* hardware, so all the values passed to the v4l2_detect_cvt/gtf
    functions came from the timings struct that was filled by userspace
    and passed on to the driver via VIDIOC_S_DV_TIMINGS. So these fields
    can contain random data. Both the constraints check via
    struct v4l2_dv_timings_cap and the additional width/height check
    ensure that the resulting timings are sane and not messed up by the
    v4l2_detect_cvt/gtf calculations.
    
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Fixes: 2576415846bc ("[media] v4l2: move dv-timings related code to v4l2-dv-timings.c")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+a828133770f62293563e@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-media/000000000000013050062127830a@google.com/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b4c6890602ac5de0d190d3fe507ab5389760cba
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Sun Oct 13 15:29:17 2024 +0200

    soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()
    
    commit c9f1efabf8e3b3ff886a42669f7093789dbeca94 upstream.
    
    of_find_compatible_node() requires a call to of_node_put() when the
    pointer to the node is not required anymore to decrement its refcount
    and avoid leaking memory.
    
    Add the missing call to of_node_put() after the node has been used.
    
    Cc: stable@vger.kernel.org
    Fixes: e95f287deed2 ("soc: fsl: handle RCPM errata A-008646 on SoC LS1021A")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20241013-rcpm-of_node_put-v1-1-9a8e55a01eae@gmail.com
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 372dc9509122e5d45d4c12978e31c3c7d00aaca4
Author: Qiu-ji Chen <chenqiuji666@gmail.com>
Date:   Fri Sep 27 16:39:02 2024 +0800

    media: wl128x: Fix atomicity violation in fmc_send_cmd()
    
    commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream.
    
    Atomicity violation occurs when the fmc_send_cmd() function is executed
    simultaneously with the modification of the fmdev->resp_skb value.
    Consider a scenario where, after passing the validity check within the
    function, a non-null fmdev->resp_skb variable is assigned a null value.
    This results in an invalid fmdev->resp_skb variable passing the validity
    check. As seen in the later part of the function, skb = fmdev->resp_skb;
    when the invalid fmdev->resp_skb passes the check, a null pointer
    dereference error may occur at line 478, evt_hdr = (void *)skb->data;
    
    To address this issue, it is recommended to include the validity check of
    fmdev->resp_skb within the locked section of the function. This
    modification ensures that the value of fmdev->resp_skb does not change
    during the validation process, thereby maintaining its validity.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations.
    
    Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources")
    Cc: stable@vger.kernel.org
    Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18023f0992ee72315f5def29013bbb8f85232c05
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Mon Oct 28 10:39:14 2024 -0700

    HID: wacom: Interpret tilt data from Intuos Pro BT as signed values
    
    commit 49a397ad24ee5e2c53a59dada2780d7e71bd3f77 upstream.
    
    The tilt data contained in the Bluetooth packets of an Intuos Pro are
    supposed to be interpreted as signed values. Simply casting the values
    to type `char` is not guaranteed to work since it is implementation-
    defined whether it is signed or unsigned. At least one user has noticed
    the data being reported incorrectly on their system. To ensure that the
    data is interpreted properly, we specifically cast to `signed char`
    instead.
    
    Link: https://github.com/linuxwacom/input-wacom/issues/445
    Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
    CC: stable@vger.kernel.org # 4.11+
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f10c6062918b2d718c21d6bf71be8611bc3ab5f
Author: Muchun Song <muchun.song@linux.dev>
Date:   Mon Oct 14 17:29:34 2024 +0800

    block: fix ordering between checking BLK_MQ_S_STOPPED request adding
    
    commit 96a9fe64bfd486ebeeacf1e6011801ffe89dae18 upstream.
    
    Supposing first scenario with a virtio_blk driver.
    
    CPU0                        CPU1
    
    blk_mq_try_issue_directly()
      __blk_mq_issue_directly()
        q->mq_ops->queue_rq()
          virtio_queue_rq()
            blk_mq_stop_hw_queue()
                                virtblk_done()
      blk_mq_request_bypass_insert()  1) store
                                  blk_mq_start_stopped_hw_queue()
                                    clear_bit(BLK_MQ_S_STOPPED)       3) store
                                    blk_mq_run_hw_queue()
                                      if (!blk_mq_hctx_has_pending()) 4) load
                                        return
                                      blk_mq_sched_dispatch_requests()
      blk_mq_run_hw_queue()
        if (!blk_mq_hctx_has_pending())
          return
        blk_mq_sched_dispatch_requests()
          if (blk_mq_hctx_stopped())  2) load
            return
          __blk_mq_sched_dispatch_requests()
    
    Supposing another scenario.
    
    CPU0                        CPU1
    
    blk_mq_requeue_work()
      blk_mq_insert_request() 1) store
                                virtblk_done()
                                  blk_mq_start_stopped_hw_queue()
      blk_mq_run_hw_queues()        clear_bit(BLK_MQ_S_STOPPED)       3) store
                                    blk_mq_run_hw_queue()
                                      if (!blk_mq_hctx_has_pending()) 4) load
                                        return
                                      blk_mq_sched_dispatch_requests()
        if (blk_mq_hctx_stopped())  2) load
          continue
        blk_mq_run_hw_queue()
    
    Both scenarios are similar, the full memory barrier should be inserted
    between 1) and 2), as well as between 3) and 4) to make sure that either
    CPU0 sees BLK_MQ_S_STOPPED is cleared or CPU1 sees dispatch list.
    Otherwise, either CPU will not rerun the hardware queue causing
    starvation of the request.
    
    The easy way to fix it is to add the essential full memory barrier into
    helper of blk_mq_hctx_stopped(). In order to not affect the fast path
    (hardware queue is not stopped most of the time), we only insert the
    barrier into the slow path. Actually, only slow path needs to care about
    missing of dispatching the request to the low-level device driver.
    
    Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism")
    Cc: stable@vger.kernel.org
    Cc: Muchun Song <muchun.song@linux.dev>
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20241014092934.53630-4-songmuchun@bytedance.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 023438d01b5793c92bab1be78624fdadf94fac83
Author: Will Deacon <will@kernel.org>
Date:   Thu Nov 14 09:53:32 2024 +0000

    arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled
    
    commit 67ab51cbdfee02ef07fb9d7d14cc0bf6cb5a5e5c upstream.
    
    Commit 18011eac28c7 ("arm64: tls: Avoid unconditional zeroing of
    tpidrro_el0 for native tasks") tried to optimise the context switching
    of tpidrro_el0 by eliding the clearing of the register when switching
    to a native task with kpti enabled, on the erroneous assumption that
    the kpti trampoline entry code would already have taken care of the
    write.
    
    Although the kpti trampoline does zero the register on entry from a
    native task, the check in tls_thread_switch() is on the *next* task and
    so we can end up leaving a stale, non-zero value in the register if the
    previous task was 32-bit.
    
    Drop the broken optimisation and zero tpidrro_el0 unconditionally when
    switching to a native 64-bit task.
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: stable@vger.kernel.org
    Fixes: 18011eac28c7 ("arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks")
    Signed-off-by: Will Deacon <will@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20241114095332.23391-1-will@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59ad8b56af1d13633d238a6cf34e0e56d17341ae
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Nov 11 19:07:18 2024 +0800

    ublk: fix ublk_ch_mmap() for 64K page size
    
    commit d369735e02ef122d19d4c3d093028da0eb400636 upstream.
    
    In ublk_ch_mmap(), queue id is calculated in the following way:
    
            (vma->vm_pgoff << PAGE_SHIFT) / `max_cmd_buf_size`
    
    'max_cmd_buf_size' is equal to
    
            `UBLK_MAX_QUEUE_DEPTH * sizeof(struct ublksrv_io_desc)`
    
    and UBLK_MAX_QUEUE_DEPTH is 4096 and part of UAPI, so 'max_cmd_buf_size'
    is always page aligned in 4K page size kernel. However, it isn't true in
    64K page size kernel.
    
    Fixes the issue by always rounding up 'max_cmd_buf_size' with PAGE_SIZE.
    
    Cc: stable@vger.kernel.org
    Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20241111110718.1394001-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b6b8e011fab680a223b5e07a3c64774156ec6fe
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Thu Jul 14 16:41:36 2022 +0800

    sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK
    
    commit 3c891f7c6a4e90bb1199497552f24b26e46383bc upstream.
    
    When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected,
    cpu_max_bits_warn() generates a runtime warning similar as below when
    showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
    instead of NR_CPUS to iterate CPUs.
    
    [    3.052463] ------------[ cut here ]------------
    [    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
    [    3.070072] Modules linked in: efivarfs autofs4
    [    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
    [    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
    [    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
    [    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
    [    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
    [    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
    [    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
    [    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
    [    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000
    [    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
    [    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
    [    3.195868]         ...
    [    3.199917] Call Trace:
    [    3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
    [    3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
    [    3.217625] [<900000000023d268>] __warn+0xd0/0x100
    [    3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
    [    3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
    [    3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
    [    3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
    [    3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
    [    3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
    [    3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
    [    3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
    [    3.281824] ---[ end trace 8b484262b4b8c24c ]---
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc5251b1af5c9a0749322bf58bd5aa673f545fe2
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Tue Nov 5 00:32:03 2024 +0800

    um: vector: Do not use drvdata in release
    
    commit 51b39d741970742a5c41136241a9c48ac607cf82 upstream.
    
    The drvdata is not available in release. Let's just use container_of()
    to get the vector_device instance. Otherwise, removing a vector device
    will result in a crash:
    
    RIP: 0033:vector_device_release+0xf/0x50
    RSP: 00000000e187bc40  EFLAGS: 00010202
    RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0
    RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000
    RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70
    R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028
    R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6
    Kernel panic - not syncing: Segfault with no mm
    CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1
    Workqueue: events mc_work_proc
    Stack:
     60028f61 623ae028 e187bc80 60276fcd
     6220b9c0 603f5820 623ae028 00000000
     e187bcb0 603a2bcd 623ae000 62370010
    Call Trace:
     [<60028f61>] ? vector_device_release+0x0/0x50
     [<60276fcd>] device_release+0x70/0xba
     [<603a2bcd>] kobject_put+0xba/0xe7
     [<60277265>] put_device+0x19/0x1c
     [<60281266>] platform_device_put+0x26/0x29
     [<60281e5f>] platform_device_unregister+0x2c/0x2e
     [<60029422>] vector_remove+0x52/0x58
     [<60031316>] ? mconsole_reply+0x0/0x50
     [<600310c8>] mconsole_remove+0x160/0x1cc
     [<603b19f4>] ? strlen+0x0/0x15
     [<60066611>] ? __dequeue_entity+0x1a9/0x206
     [<600666a7>] ? set_next_entity+0x39/0x63
     [<6006666e>] ? set_next_entity+0x0/0x63
     [<60038fa6>] ? um_set_signals+0x0/0x43
     [<6003070c>] mc_work_proc+0x77/0x91
     [<60057664>] process_scheduled_works+0x1b3/0x2dd
     [<60055f32>] ? assign_work+0x0/0x58
     [<60057f0a>] worker_thread+0x1e9/0x293
     [<6005406f>] ? set_pf_worker+0x0/0x64
     [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
     [<6005d748>] ? kthread_exit+0x0/0x3a
     [<60057d21>] ? worker_thread+0x0/0x293
     [<6005dbf1>] kthread+0x126/0x12b
     [<600219c5>] new_thread_handler+0x85/0xb6
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Link: https://patch.msgid.link/20241104163203.435515-5-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03d1f525d46824dc0fe1c100d43af0cc1edad94c
Author: Bin Liu <b-liu@ti.com>
Date:   Thu Oct 31 12:23:15 2024 -0500

    serial: 8250: omap: Move pm_runtime_get_sync
    
    commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream.
    
    Currently in omap_8250_shutdown, the dma->rx_running flag is
    set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync
    is called, which is a runtime resume call stack which can
    re-set the flag. When the call omap_8250_shutdown returns, the
    flag is expected to be UN-SET, but this is not the case. This
    is causing issues the next time UART is re-opened and
    omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync
    before the omap_8250_rx_dma_flush.
    
    cc: stable@vger.kernel.org
    Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback")
    Signed-off-by: Bin Liu <b-liu@ti.com>
    [Judith: Add commit message]
    Signed-off-by: Judith Mendez <jm@ti.com>
    Reviewed-by: Kevin Hilman <khilman@baylibre.com>
    Tested-by: Kevin Hilman <khilman@baylibre.com>
    Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef42e3edf9cb7a3b4064f05ca72e5f6c9d6ad774
Author: Filip Brozovic <fbrozovic@gmail.com>
Date:   Sun Nov 10 12:17:00 2024 +0100

    serial: 8250_fintek: Add support for F81216E
    
    commit 166105c9030a30ba08574a9998afc7b60bc72dd7 upstream.
    
    The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with
    the F81216H, but does not support RS-485 auto-direction delays on any port.
    
    Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 170011e92246903c5155dc8a3e7925e445f269f4
Author: Michal Simek <michal.simek@amd.com>
Date:   Mon Sep 16 11:53:06 2024 +0200

    dt-bindings: serial: rs485: Fix rs485-rts-delay property
    
    commit 12b3642b6c242061d3ba84e6e3050c3141ded14c upstream.
    
    Code expects array only with 2 items which should be checked.
    But also item checking is not working as it should likely because of
    incorrect items description.
    
    Fixes: d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema")
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 160cd5f956d191eb97664afd31ca59284c08d876
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Tue Nov 5 00:32:02 2024 +0800

    um: net: Do not use drvdata in release
    
    commit d1db692a9be3b4bd3473b64fcae996afaffe8438 upstream.
    
    The drvdata is not available in release. Let's just use container_of()
    to get the uml_net instance. Otherwise, removing a network device will
    result in a crash:
    
    RIP: 0033:net_device_release+0x10/0x6f
    RSP: 00000000e20c7c40  EFLAGS: 00010206
    RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0
    RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028
    RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70
    R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000
    R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6
    Kernel panic - not syncing: Segfault with no mm
    CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1
    Workqueue: events mc_work_proc
    Stack:
     627af028 62c7af00 e20c7c80 60276fcd
     62778000 603f5820 627af028 00000000
     e20c7cb0 603a2bcd 627af000 62770010
    Call Trace:
     [<60276fcd>] device_release+0x70/0xba
     [<603a2bcd>] kobject_put+0xba/0xe7
     [<60277265>] put_device+0x19/0x1c
     [<60281266>] platform_device_put+0x26/0x29
     [<60281e5f>] platform_device_unregister+0x2c/0x2e
     [<6002ec9c>] net_remove+0x63/0x69
     [<60031316>] ? mconsole_reply+0x0/0x50
     [<600310c8>] mconsole_remove+0x160/0x1cc
     [<60087d40>] ? __remove_hrtimer+0x38/0x74
     [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98
     [<6006b3cf>] ? dl_server_stop+0x3f/0x48
     [<6006b390>] ? dl_server_stop+0x0/0x48
     [<600672e8>] ? dequeue_entities+0x327/0x390
     [<60038fa6>] ? um_set_signals+0x0/0x43
     [<6003070c>] mc_work_proc+0x77/0x91
     [<60057664>] process_scheduled_works+0x1b3/0x2dd
     [<60055f32>] ? assign_work+0x0/0x58
     [<60057f0a>] worker_thread+0x1e9/0x293
     [<6005406f>] ? set_pf_worker+0x0/0x64
     [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
     [<6005d748>] ? kthread_exit+0x0/0x3a
     [<60057d21>] ? worker_thread+0x0/0x293
     [<6005dbf1>] kthread+0x126/0x12b
     [<600219c5>] new_thread_handler+0x85/0xb6
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Link: https://patch.msgid.link/20241104163203.435515-4-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a75207efae4b558aaa34c288de7d6f2e926b4b
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Tue Nov 5 00:32:01 2024 +0800

    um: ubd: Do not use drvdata in release
    
    commit 5bee35e5389f450a7eea7318deb9073e9414d3b1 upstream.
    
    The drvdata is not available in release. Let's just use container_of()
    to get the ubd instance. Otherwise, removing a ubd device will result
    in a crash:
    
    RIP: 0033:blk_mq_free_tag_set+0x1f/0xba
    RSP: 00000000e2083bf0  EFLAGS: 00010246
    RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00
    RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348
    RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7
    R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000
    R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0
    Kernel panic - not syncing: Segfault with no mm
    CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1
    Workqueue: events mc_work_proc
    Stack:
     00000000 604f7ef0 62c5d000 62405d20
     e2083c30 6002c776 6002c755 600e47ff
     e2083c60 6025ffe3 04208060 603d36e0
    Call Trace:
     [<6002c776>] ubd_device_release+0x21/0x55
     [<6002c755>] ? ubd_device_release+0x0/0x55
     [<600e47ff>] ? kfree+0x0/0x100
     [<6025ffe3>] device_release+0x70/0xba
     [<60381d6a>] kobject_put+0xb5/0xe2
     [<6026027b>] put_device+0x19/0x1c
     [<6026a036>] platform_device_put+0x26/0x29
     [<6026ac5a>] platform_device_unregister+0x2c/0x2e
     [<6002c52e>] ubd_remove+0xb8/0xd6
     [<6002bb74>] ? mconsole_reply+0x0/0x50
     [<6002b926>] mconsole_remove+0x160/0x1cc
     [<6002bbbc>] ? mconsole_reply+0x48/0x50
     [<6003379c>] ? um_set_signals+0x3b/0x43
     [<60061c55>] ? update_min_vruntime+0x14/0x70
     [<6006251f>] ? dequeue_task_fair+0x164/0x235
     [<600620aa>] ? update_cfs_group+0x0/0x40
     [<603a0e77>] ? __schedule+0x0/0x3ed
     [<60033761>] ? um_set_signals+0x0/0x43
     [<6002af6a>] mc_work_proc+0x77/0x91
     [<600520b4>] process_scheduled_works+0x1af/0x2c3
     [<6004ede3>] ? assign_work+0x0/0x58
     [<600527a1>] worker_thread+0x2f7/0x37a
     [<6004ee3b>] ? set_pf_worker+0x0/0x64
     [<6005765d>] ? arch_local_irq_save+0x0/0x2d
     [<60058e07>] ? kthread_exit+0x0/0x3a
     [<600524aa>] ? worker_thread+0x0/0x37a
     [<60058f9f>] kthread+0x130/0x135
     [<6002068e>] new_thread_handler+0x85/0xb6
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a3dbe75b201b374fabbe111159116141a457b51
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Aug 19 11:26:21 2024 +0800

    ubi: wl: Put source PEB into correct list if trying locking LEB failed
    
    commit d610020f030bec819f42de327c2bd5437d2766b3 upstream.
    
    During wear-leveing work, the source PEB will be moved into scrub list
    when source LEB cannot be locked in ubi_eba_copy_leb(), which is wrong
    for non-scrub type source PEB. The problem could bring extra and
    ineffective wear-leveing jobs, which makes more or less negative effects
    for the life time of flash. Specifically, the process is divided 2 steps:
    1. wear_leveling_worker // generate false scrub type PEB
         ubi_eba_copy_leb // MOVE_RETRY is returned
           leb_write_trylock // trylock failed
         scrubbing = 1;
         e1 is put into ubi->scrub
    2. wear_leveling_worker // schedule false scrub type PEB for wl
         scrubbing = 1
         e1 = rb_entry(rb_first(&ubi->scrub))
    
    The problem can be reproduced easily by running fsstress on a small
    UBIFS partition(<64M, simulated by nandsim) for 5~10mins
    (CONFIG_MTD_UBI_FASTMAP=y,CONFIG_MTD_UBI_WL_THRESHOLD=50). Following
    message is shown:
     ubi0: scrubbed PEB 66 (LEB 0:10), data moved to PEB 165
    
    Since scrub type source PEB has set variable scrubbing as '1', and
    variable scrubbing is checked before variable keep, so the problem can
    be fixed by setting keep variable as 1 directly if the source LEB cannot
    be locked.
    
    Fixes: e801e128b220 ("UBI: fix missing scrub when there is a bit-flip")
    CC: stable@vger.kernel.org
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d427e3aa8486b7e95fb562ae7619a3db9d3286b1
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Sun Oct 13 15:20:24 2024 +0200

    platform/chrome: cros_ec_typec: fix missing fwnode reference decrement
    
    commit 9c41f371457bd9a24874e3c7934d9745e87fbc58 upstream.
    
    The device_for_each_child_node() macro requires explicit calls to
    fwnode_handle_put() upon early exits (return, break, goto) to decrement
    the fwnode's refcount, and avoid levaing a node reference behind.
    
    Add the missing fwnode_handle_put() after the common label for all error
    paths.
    
    Cc: stable@vger.kernel.org
    Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20241013-cross_ec_typec_fwnode_handle_put-v2-1-9182b2cd7767@gmail.com
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 082dc185b8619c6ec8d05ed58e36c4a5c9b315ba
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Oct 2 14:32:04 2024 -0700

    parisc/ftrace: Fix function graph tracing disablement
    
    commit a5f05a138a8cac035bf9da9b6ed0e532bc7942c8 upstream.
    
    Due to an apparent copy-paste bug, the parisc implementation of
    ftrace_disable_ftrace_graph_caller() doesn't actually do anything.
    It enables the (already-enabled) static key rather than disabling it.
    
    The result is that after function graph tracing has been "disabled", any
    subsequent (non-graph) function tracing will inadvertently also enable
    the slow fgraph return address hijacking.
    
    Fixes: 98f2926171ae ("parisc/ftrace: use static key to enable/disable function graph tracer")
    Cc: stable@vger.kernel.org # 5.16+
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c923c437ed69d44ee3753f9cf47d48d2a53d26f7
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Nov 7 19:38:41 2024 +0800

    cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()
    
    commit 172bf5ed04cb6c9e66d58de003938ed5c8756570 upstream.
    
    mtk_cpufreq_get_cpu_power() return 0 if the policy is NULL. Then in
    em_create_perf_table(), the later zero check for power is not invalid
    as power is uninitialized. As Lukasz suggested, it must return -EINVAL when
    the 'policy' is not found. So return -EINVAL to fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Suggested-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1050f5871588b469af8b1c8a4495ab867b1454e2
Author: Cheng Ming Lin <chengminglin@mxic.com.tw>
Date:   Tue Nov 12 15:52:42 2024 +0800

    mtd: spi-nor: core: replace dummy buswidth from addr to data
    
    commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795 upstream.
    
    The default dummy cycle for Macronix SPI NOR flash in Octal Output
    Read Mode(1-1-8) is 20.
    
    Currently, the dummy buswidth is set according to the address bus width.
    In the 1-1-8 mode, this means the dummy buswidth is 1. When converting
    dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the
    host to read data 4 cycles too early.
    
    Since the protocol data buswidth is always greater than or equal to the
    address buswidth. Setting the dummy buswidth to match the data buswidth
    increases the likelihood that the dummy cycle-to-byte conversion will be
    divisible, preventing the host from reading data prematurely.
    
    Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol")
    Cc: stable@vger.kernel.org
    Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
    Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
    Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com
    Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f69123bb5c79fd9c85f6be5fa4571e7561708330
Author: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Date:   Fri Nov 22 10:42:24 2024 +0100

    spi: Fix acpi deferred irq probe
    
    commit d24cfee7f63d6b44d45a67c5662bd1cc48e8b3ca upstream.
    
    When probing spi device take care of deferred probe of ACPI irq gpio
    similar like for OF/DT case.
    
    >From practical standpoint this fixes issue with vsc-tp driver on
    Dell XP 9340 laptop, which try to request interrupt with spi->irq
    equal to -EPROBE_DEFER and fail to probe with the following error:
    
    vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22
    
    Suggested-by: Hans de Goede <hdegoede@redhat.com>
    Fixes: 33ada67da352 ("ACPI / spi: attach GPIO IRQ from ACPI description to SPI device")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> # Dell XPS9320, ov01a10
    Link: https://patch.msgid.link/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ffef5e5d5eeecd9687204a5ec2d863752aafb7e
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Wed Nov 13 22:02:09 2024 +0900

    netfilter: ipset: add missing range check in bitmap_ip_uadt
    
    commit 35f56c554eb1b56b77b3cf197a6b00922d49033d upstream.
    
    When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
    the values of ip and ip_to are slightly swapped. Therefore, the range check
    for ip should be done later, but this part is missing and it seems that the
    vulnerability occurs.
    
    So we should add missing range checks and remove unnecessary range checks.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: syzbot+58c872f7790a4d2ac951@syzkaller.appspotmail.com
    Fixes: 72205fc68bd1 ("netfilter: ipset: bitmap:ip set type support")
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69418eec0c9746cbf6d3f2f0666b4f7270bf25c8
Author: Sai Kumar Cholleti <skmr537@gmail.com>
Date:   Tue Nov 5 12:45:23 2024 +0530

    gpio: exar: set value when external pull-up or pull-down is present
    
    commit 72cef64180de04a7b055b4773c138d78f4ebdb77 upstream.
    
    Setting GPIO direction = high, sometimes results in GPIO value = 0.
    
    If a GPIO is pulled high, the following construction results in the
    value being 0 when the desired value is 1:
    
    $ echo "high" > /sys/class/gpio/gpio336/direction
    $ cat /sys/class/gpio/gpio336/value
    0
    
    Before the GPIO direction is changed from an input to an output,
    exar_set_value() is called with value = 1, but since the GPIO is an
    input when exar_set_value() is called, _regmap_update_bits() reads a 1
    due to an external pull-up.  regmap_set_bits() sets force_write =
    false, so the value (1) is not written.  When the direction is then
    changed, the GPIO becomes an output with the value of 0 (the hardware
    default).
    
    regmap_write_bits() sets force_write = true, so the value is always
    written by exar_set_value() and an external pull-up doesn't affect the
    outcome of setting direction = high.
    
    The same can happen when a GPIO is pulled low, but the scenario is a
    little more complicated.
    
    $ echo high > /sys/class/gpio/gpio351/direction
    $ cat /sys/class/gpio/gpio351/value
    1
    
    $ echo in > /sys/class/gpio/gpio351/direction
    $ cat /sys/class/gpio/gpio351/value
    0
    
    $ echo low > /sys/class/gpio/gpio351/direction
    $ cat /sys/class/gpio/gpio351/value
    1
    
    Fixes: 36fb7218e878 ("gpio: exar: switch to using regmap")
    Co-developed-by: Matthew McClain <mmcclain@noprivs.com>
    Signed-off-by: Matthew McClain <mmcclain@noprivs.com>
    Signed-off-by: Sai Kumar Cholleti <skmr537@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20241105071523.2372032-1-skmr537@gmail.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51c8380cc4b2cb278e38df9e548c5bff448b9366
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Nov 30 16:55:56 2024 +0100

    Revert "serial: sh-sci: Clean sci_ports[0] after at earlycon exit"
    
    commit 718632467d88e98816fa01ab12681ef1c2aa56f8 upstream.
    
    This reverts commit 3791ea69a4858b81e0277f695ca40f5aae40f312.
    
    It was reported to cause boot-time issues, so revert it for now.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Fixes: 3791ea69a485 ("serial: sh-sci: Clean sci_ports[0] after at earlycon exit")
    Cc: stable <stable@kernel.org>
    Cc: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a558edf0fcd430f13fce979fbc5eb9cfce71f04
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Wed Nov 6 14:01:12 2024 +0200

    serial: sh-sci: Clean sci_ports[0] after at earlycon exit
    
    commit 3791ea69a4858b81e0277f695ca40f5aae40f312 upstream.
    
    The early_console_setup() function initializes the sci_ports[0].port with
    an object of type struct uart_port obtained from the object of type
    struct earlycon_device received as argument by the early_console_setup().
    
    It may happen that later, when the rest of the serial ports are probed,
    the serial port that was used as earlycon (e.g., port A) to be mapped to a
    different position in sci_ports[] and the slot 0 to be used by a different
    serial port (e.g., port B), as follows:
    
    sci_ports[0] = port A
    sci_ports[X] = port B
    
    In this case, the new port mapped at index zero will have associated data
    that was used for earlycon.
    
    In case this happens, after Linux boot, any access to the serial port that
    maps on sci_ports[0] (port A) will block the serial port that was used as
    earlycon (port B).
    
    To fix this, add early_console_exit() that clean the sci_ports[0] at
    earlycon exit time.
    
    Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Link: https://lore.kernel.org/r/20241106120118.1719888-4-claudiu.beznea.uj@bp.renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c17418f43acc086f3be5efe7fa55eb1308ac022f
Author: Michal Vrastil <michal.vrastil@hidglobal.com>
Date:   Wed Nov 13 15:54:33 2024 -0800

    Revert "usb: gadget: composite: fix OS descriptors w_value logic"
    
    commit 51cdd69d6a857f527d6d0697a2e1f0fa8bca1005 upstream.
    
    This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.
    
    Fix installation of WinUSB driver using OS descriptors. Without the
    fix the drivers are not installed correctly and the property
    'DeviceInterfaceGUID' is missing on host side.
    
    The original change was based on the assumption that the interface
    number is in the high byte of wValue but it is in the low byte,
    instead. Unfortunately, the fix is based on MS documentation which is
    also wrong.
    
    The actual USB request for OS descriptors (using USB analyzer) looks
    like:
    
    Offset  0   1   2   3   4   5   6   7
    0x000   C1  A1  02  00  05  00  0A  00
    
    C1: bmRequestType (device to host, vendor, interface)
    A1: nas magic number
    0002: wValue (2: nas interface)
    0005: wIndex (5: get extended property i.e. nas interface GUID)
    008E: wLength (142)
    
    The fix was tested on Windows 10 and Windows 11.
    
    Cc: stable@vger.kernel.org
    Fixes: ec6ce7075ef8 ("usb: gadget: composite: fix OS descriptors w_value logic")
    Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
    Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
    Acked-by: Peter korsgaard <peter@korsgaard.com>
    Link: https://lore.kernel.org/r/20241113235433.20244-1-quic_eserrao@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e696b979061de3fc482b01b343d2d0fd1248900
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Wed Oct 30 18:34:45 2024 +0100

    wifi: brcmfmac: release 'root' node in all execution paths
    
    commit 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d upstream.
    
    The fixed patch introduced an additional condition to enter the scope
    where the 'root' device_node is released (!settings->board_type,
    currently 'err'), which avoid decrementing the refcount with a call to
    of_node_put() if that second condition is not satisfied.
    
    Move the call to of_node_put() to the point where 'root' is no longer
    required to avoid leaking the resource if err is not zero.
    
    Cc: stable@vger.kernel.org
    Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241030-brcmfmac-of-cleanup-v1-1-0b90eefb4279@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c386fb76f01794f1023d01a6ec5f5c93d00acd3b
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Fri Nov 1 16:30:05 2024 -0300

    wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
    
    commit 5c1b544563005a00591a3aa86ecff62ed4d11be3 upstream.
    
    Syzkaller reported a hung task with uevent_show() on stack trace. That
    specific issue was addressed by another commit [0], but even with that
    fix applied (for example, running v6.12-rc5) we face another type of hung
    task that comes from the same reproducer [1]. By investigating that, we
    could narrow it to the following path:
    
    (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
    dummy_hcd infrastructure.
    
    (b) During the probe of rtl8192cu, the driver ends-up performing an efuse
    read procedure (which is related to EEPROM load IIUC), and here lies the
    issue: the function read_efuse() calls read_efuse_byte() many times, as
    loop iterations depending on the efuse size (in our example, 512 in total).
    
    This procedure for reading efuse bytes relies in a loop that performs an
    I/O read up to *10k* times in case of failures. We measured the time of
    the loop inside read_efuse_byte() alone, and in this reproducer (which
    involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
    consequence, we have the driver stuck in its probe routine for big time,
    exposing a stack trace like below if we attempt to reboot the system, for
    example:
    
    task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000
    Workqueue: usb_hub_wq hub_event
    Call Trace:
     __schedule+0xe22/0xeb6
     schedule_timeout+0xe7/0x132
     __wait_for_common+0xb5/0x12e
     usb_start_wait_urb+0xc5/0x1ef
     ? usb_alloc_urb+0x95/0xa4
     usb_control_msg+0xff/0x184
     _usbctrl_vendorreq_sync+0xa0/0x161
     _usb_read_sync+0xb3/0xc5
     read_efuse_byte+0x13c/0x146
     read_efuse+0x351/0x5f0
     efuse_read_all_map+0x42/0x52
     rtl_efuse_shadow_map_update+0x60/0xef
     rtl_get_hwinfo+0x5d/0x1c2
     rtl92cu_read_eeprom_info+0x10a/0x8d5
     ? rtl92c_read_chip_version+0x14f/0x17e
     rtl_usb_probe+0x323/0x851
     usb_probe_interface+0x278/0x34b
     really_probe+0x202/0x4a4
     __driver_probe_device+0x166/0x1b2
     driver_probe_device+0x2f/0xd8
     [...]
    
    We propose hereby to drastically reduce the attempts of doing the I/O
    reads in case of failures, restricted to USB devices (given that
    they're inherently slower than PCIe ones). By retrying up to 10 times
    (instead of 10000), we got reponsiveness in the reproducer, while seems
    reasonable to believe that there's no sane USB device implementation in
    the field requiring this amount of retries at every I/O read in order
    to properly work. Based on that assumption, it'd be good to have it
    backported to stable but maybe not since driver implementation (the 10k
    number comes from day 0), perhaps up to 6.x series makes sense.
    
    [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")
    
    [1] A note about that: this syzkaller report presents multiple reproducers
    that differs by the type of emulated USB device. For this specific case,
    check the entry from 2024/08/08 06:23 in the list of crashes; the C repro
    is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
    
    Cc: stable@vger.kernel.org # v6.1+
    Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com
    Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc1f391a71a3ee88291e205cffd673fe24d99266
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Sat Jul 27 16:34:01 2024 +0800

    driver core: bus: Fix double free in driver API bus_register()
    
    commit bfa54a793ba77ef696755b66f3ac4ed00c7d1248 upstream.
    
    For bus_register(), any error which happens after kset_register() will
    cause that @priv are freed twice, fixed by setting @priv with NULL after
    the first free.
    
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20240727-bus_register_fix-v1-1-fed8dd0dba7a@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [ Brennan : Backport requires bus->p = NULL instead of priv = NULL ]
    Signed-off-by: Brennan Lamoreaux <brennan.lamoreaux@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d5a63a0bc860c441c4e5dcf28ec8036c9d3b2463
Author: Michal Pecio <michal.pecio@gmail.com>
Date:   Wed Nov 6 12:14:58 2024 +0200

    usb: xhci: Fix TD invalidation under pending Set TR Dequeue
    
    commit 484c3bab2d5dfa13ff659a51a06e9a393141eefc upstream.
    
    xhci_invalidate_cancelled_tds() may not work correctly if the hardware
    is modifying endpoint or stream contexts at the same time by executing
    a Set TR Dequeue command. And even if it worked, it would be unable to
    queue Set TR Dequeue for the next stream, failing to clear xHC cache.
    
    On stream endpoints, a chain of Set TR Dequeue commands may take some
    time to execute and we may want to cancel more TDs during this time.
    Currently this leads to Stop Endpoint completion handler calling this
    function without testing for SET_DEQ_PENDING, which will trigger the
    aforementioned problems when it happens.
    
    On all endpoints, a halt condition causes Reset Endpoint to be queued
    and an error status given to the class driver, which may unlink more
    URBs in response. Stop Endpoint is queued and its handler may execute
    concurrently with Set TR Dequeue queued by Reset Endpoint handler.
    
    (Reset Endpoint handler calls this function too, but there seems to
    be no possibility of it running concurrently with Set TR Dequeue).
    
    Fix xhci_invalidate_cancelled_tds() to work correctly under a pending
    Set TR Dequeue. Bail out of the function when SET_DEQ_PENDING is set,
    then make the completion handler call the function again and also call
    xhci_giveback_invalidated_tds(), which needs to be called next.
    
    This seems to fix another potential bug, where the handler would call
    xhci_invalidate_cancelled_tds(), which may clear some deferred TDs if
    a sanity check fails, and the TDs wouldn't be given back promptly.
    
    Said sanity check seems to be wrong and prone to false positives when
    the endpoint halts, but fixing it is beyond the scope of this change,
    besides ensuring that cleared TDs are given back properly.
    
    Fixes: 5ceac4402f5d ("xhci: Handle TD clearing for multiple streams case")
    CC: stable@vger.kernel.org
    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20241106101459.775897-33-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e07ab9ad3d35effe62054ac7fe3bd76a2652e13
Author: Andrej Shadura <andrew.shadura@collabora.co.uk>
Date:   Wed Oct 9 14:14:24 2024 +0200

    Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()
    
    commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream.
    
    Commit 9bf4e919ccad worked around an issue introduced after an innocuous
    optimisation change in LLVM main:
    
    > len is defined as an 'int' because it is assigned from
    > '__user int *optlen'. However, it is clamped against the result of
    > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
    > platforms). This is done with min_t() because min() requires compatible
    > types, which results in both len and the result of sizeof() being casted
    > to 'unsigned int', meaning len changes signs and the result of sizeof()
    > is truncated. From there, len is passed to copy_to_user(), which has a
    > third parameter type of 'unsigned long', so it is widened and changes
    > signs again. This excessive casting in combination with the KCSAN
    > instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
    > call, failing the build.
    
    The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and
    rfcomm_sock_getsockopt_old.
    
    Change the type of len to size_t in both rfcomm_sock_getsockopt and
    rfcomm_sock_getsockopt_old and replace min_t() with min().
    
    Cc: stable@vger.kernel.org
    Co-authored-by: Aleksei Vetrov <vvvvvv@google.com>
    Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()")
    Link: https://github.com/ClangBuiltLinux/linux/issues/2007
    Link: https://github.com/llvm/llvm-project/issues/85647
    Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d84150aab31e3717f71d95d7a98ea687deffe2d7
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sat Oct 26 13:06:15 2024 +0900

    exfat: fix uninit-value in __exfat_get_dentry_set
    
    commit 02dffe9ab092fc4c8800aee68cb7eafd37a980c4 upstream.
    
    There is no check if stream size and start_clu are invalid.
    If start_clu is EOF cluster and stream size is 4096, It will
    cause uninit value access. because ei->hint_femp.eidx could
    be 128(if cluster size is 4K) and wrong hint will allocate
    next cluster. and this cluster will be same with the cluster
    that is allocated by exfat_extend_valid_size(). The previous
    patch will check invalid start_clu, but for clarity, initialize
    hint_femp.eidx to zero.
    
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+01218003be74b5e1213a@syzkaller.appspotmail.com
    Tested-by: syzbot+01218003be74b5e1213a@syzkaller.appspotmail.com
    Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a9244a3924de1bf439256e46d5c99c68595b00
Author: Angelo Dureghello <adureghello@baylibre.com>
Date:   Thu Oct 3 19:29:01 2024 +0200

    dt-bindings: iio: dac: ad3552r: fix maximum spi speed
    
    commit d1d1c117f39b2057d1e978f26a8bd9631ddb193b upstream.
    
    Fix maximum SPI clock speed, as per datasheet (Rev. B, page 6).
    
    Fixes: b0a96c5f599e ("dt-bindings: iio: dac: Add adi,ad3552r.yaml")
    Cc: stable@vger.kernel.org
    Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://patch.msgid.link/20241003-wip-bl-ad3552r-axi-v0-iio-testing-v4-4-ceb157487329@baylibre.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a27ca3da0d129d2df57ef737fe5589c31e014f0
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Oct 25 14:16:22 2024 +0200

    pinctrl: qcom: spmi: fix debugfs drive strength
    
    commit 6bc0ebfb1d920f13c522545f114cdabb49e9408a upstream.
    
    Commit 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength
    mapping") fixed a long-standing issue in the Qualcomm SPMI PMIC gpio
    driver which had the 'low' and 'high' drive strength settings switched
    but failed to update the debugfs interface which still gets this wrong.
    
    Fix the debugfs code so that the exported values match the hardware
    settings.
    
    Note that this probably means that most devicetrees that try to describe
    the firmware settings got this wrong if the settings were derived from
    debugfs. Before the above mentioned commit the settings would have
    actually matched the firmware settings even if they were described
    incorrectly, but now they are inverted.
    
    Fixes: 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping")
    Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
    Cc: Anjelique Melendez <quic_amelende@quicinc.com>
    Cc: stable@vger.kernel.org      # 3.19
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/20241025121622.1496-1-johan+linaro@kernel.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be063ffa28bcbf2ac7e803dea5f27ffa3b9254f8
Author: Ahmed Ehab <bottaawesome633@gmail.com>
Date:   Sun Aug 25 01:10:30 2024 +0300

    locking/lockdep: Avoid creating new name string literals in lockdep_set_subclass()
    
    commit d7fe143cb115076fed0126ad8cf5ba6c3e575e43 upstream.
    
    Syzbot reports a problem that a warning will be triggered while
    searching a lock class in look_up_lock_class().
    
    The cause of the issue is that a new name is created and used by
    lockdep_set_subclass() instead of using the existing one. This results
    in a lock instance has a different name pointer than previous registered
    one stored in lock class, and WARN_ONCE() is triggered because of that
    in look_up_lock_class().
    
    To fix this, change lockdep_set_subclass() to use the existing name
    instead of a new one. Hence, no new name will be created by
    lockdep_set_subclass(). Hence, the warning is avoided.
    
    [boqun: Reword the commit log to state the correct issue]
    
    Reported-by: <syzbot+7f4a6f7f7051474e40ad@syzkaller.appspotmail.com>
    Fixes: de8f5e4f2dc1f ("lockdep: Introduce wait-type checks")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ahmed Ehab <bottaawesome633@gmail.com>
    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    Link: https://lore.kernel.org/lkml/20240824221031.7751-1-bottaawesome633@gmail.com/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 445faec21f47768e22caca33c409af00b17d037b
Author: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
Date:   Tue Nov 12 14:13:31 2024 +0100

    tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler
    
    commit 635a9fca54f4f4148be1ae1c7c6bd37af80f5773 upstream.
    
    Commit 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of
    ldiscs") introduces the tty_ldisc_autoload sysctl with the wrong
    proc_handler. .extra1 and .extra2 parameters are set to avoid other values
    thant SYSCTL_ZERO or SYSCTL_ONE to be set but proc_dointvec do not uses
    them.
    
    This commit fixes this by using proc_dointvec_minmax instead of
    proc_dointvec.
    
    Fixes: 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
    Reviewed-by: Lin Feng <linf@wangsu.com>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20241112131357.49582-4-nicolas.bouchinet@clip-os.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89265f88701e54dde255ddf862093baeca57548c
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Oct 11 09:22:41 2024 +0800

    apparmor: test: Fix memory leak for aa_unpack_strdup()
    
    commit 7290f59231910ccba427d441a6e8b8c6f6112448 upstream.
    
    The string allocated by kmemdup() in aa_unpack_strdup() is not
    freed and cause following memory leaks, free them to fix it.
    
            unreferenced object 0xffffff80c6af8a50 (size 8):
              comm "kunit_try_catch", pid 225, jiffies 4294894407
              hex dump (first 8 bytes):
                74 65 73 74 69 6e 67 00                          testing.
              backtrace (crc 5eab668b):
                [<0000000001e3714d>] kmemleak_alloc+0x34/0x40
                [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0
                [<000000006870467c>] kmemdup_noprof+0x34/0x60
                [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c
                [<000000008ecde918>] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec
                [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac
                [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec
                [<00000000adf936cf>] kthread+0x2e8/0x374
                [<0000000041bb1628>] ret_from_fork+0x10/0x20
            unreferenced object 0xffffff80c2a29090 (size 8):
              comm "kunit_try_catch", pid 227, jiffies 4294894409
              hex dump (first 8 bytes):
                74 65 73 74 69 6e 67 00                          testing.
              backtrace (crc 5eab668b):
                [<0000000001e3714d>] kmemleak_alloc+0x34/0x40
                [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0
                [<000000006870467c>] kmemdup_noprof+0x34/0x60
                [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c
                [<0000000046a45c1a>] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4
                [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac
                [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec
                [<00000000adf936cf>] kthread+0x2e8/0x374
                [<0000000041bb1628>] ret_from_fork+0x10/0x20
    
    Cc: stable@vger.kernel.org
    Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16c507df509113c037cdc0ba642b9ab3389bd26c
Author: Jann Horn <jannh@google.com>
Date:   Thu Oct 17 21:07:45 2024 +0200

    comedi: Flush partial mappings in error case
    
    commit ce8f9fb651fac95dd41f69afe54d935420b945bd upstream.
    
    If some remap_pfn_range() calls succeeded before one failed, we still have
    buffer pages mapped into the userspace page tables when we drop the buffer
    reference with comedi_buf_map_put(bm). The userspace mappings are only
    cleaned up later in the mmap error path.
    
    Fix it by explicitly flushing all mappings in our VMA on the error path.
    
    See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
    error case").
    
    Cc: stable@vger.kernel.org
    Fixes: ed9eccbe8970 ("Staging: add comedi core")
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20241017-comedi-tlb-v3-1-16b82f9372ce@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65988ab857cc83be2e47d757f82c7373e3042426
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Wed Nov 13 16:40:34 2024 +0100

    fsnotify: fix sending inotify event with unexpected filename
    
    commit aa52c54da40d9eee3ba87c05cdcb0cd07c04fa13 upstream.
    
    We got a report that adding a fanotify filsystem watch prevents tail -f
    from receiving events.
    
    Reproducer:
    
    1. Create 3 windows / login sessions. Become root in each session.
    2. Choose a mounted filesystem that is pretty quiet; I picked /boot.
    3. In the first window, run: fsnotifywait -S -m /boot
    4. In the second window, run: echo data >> /boot/foo
    5. In the third window, run: tail -f /boot/foo
    6. Go back to the second window and run: echo more data >> /boot/foo
    7. Observe that the tail command doesn't show the new data.
    8. In the first window, hit control-C to interrupt fsnotifywait.
    9. In the second window, run: echo still more data >> /boot/foo
    10. Observe that the tail command in the third window has now printed
    the missing data.
    
    When stracing tail, we observed that when fanotify filesystem mark is
    set, tail does get the inotify event, but the event is receieved with
    the filename:
    
    read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0foo\0\0\0\0\0\0\0\0\0\0\0\0\0",
    50) = 32
    
    This is unexpected, because tail is watching the file itself and not its
    parent and is inconsistent with the inotify event received by tail when
    fanotify filesystem mark is not set:
    
    read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0", 50) = 16
    
    The inteference between different fsnotify groups was caused by the fact
    that the mark on the sb requires the filename, so the filename is passed
    to fsnotify().  Later on, fsnotify_handle_event() tries to take care of
    not passing the filename to groups (such as inotify) that are interested
    in the filename only when the parent is watching.
    
    But the logic was incorrect for the case that no group is watching the
    parent, some groups are watching the sb and some watching the inode.
    
    Reported-by: Miklos Szeredi <miklos@szeredi.hu>
    Fixes: 7372e79c9eb9 ("fanotify: fix logic of reporting name info with watched parent")
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20502f0b3f3acd6bee300257556c27a867f80c8b
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Oct 10 19:10:34 2024 +0200

    PCI: Fix use-after-free of slot->bus on hot remove
    
    commit c7acef99642b763ba585f4a43af999fcdbcc3dc4 upstream.
    
    Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.
    
    Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and
    commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot
    firmware"), USB4 v2 and v1 Host Routers are reset on probe of the
    thunderbolt driver.
    
    The reset clears the Presence Detect State and Data Link Layer Link Active
    bits at the USB4 Host Router's Root Port and thus causes hot removal of the
    dock.
    
    The crash occurs when pciehp is unbound from one of the dock's Downstream
    Ports:  pciehp creates a pci_slot on bind and destroys it on unbind.  The
    pci_slot contains a pointer to the pci_bus below the Downstream Port, but
    a reference on that pci_bus is never acquired.  The pci_bus is destroyed
    before the pci_slot, so a use-after-free ensues when pci_slot_release()
    accesses slot->bus.
    
    In principle this should not happen because pci_stop_bus_device() unbinds
    pciehp (and therefore destroys the pci_slot) before the pci_bus is
    destroyed by pci_remove_bus_device().
    
    However the stacktrace provided by Dennis shows that pciehp is unbound from
    pci_remove_bus_device() instead of pci_stop_bus_device().  To understand
    the significance of this, one needs to know that the PCI core uses a two
    step process to remove a portion of the hierarchy:  It first unbinds all
    drivers in the sub-hierarchy in pci_stop_bus_device() and then actually
    removes the devices in pci_remove_bus_device().  There is no precaution to
    prevent driver binding in-between pci_stop_bus_device() and
    pci_remove_bus_device().
    
    In Dennis' case, it seems removal of the hierarchy by pciehp races with
    driver binding by pci_bus_add_devices().  pciehp is bound to the
    Downstream Port after pci_stop_bus_device() has run, so it is unbound by
    pci_remove_bus_device() instead of pci_stop_bus_device().  Because the
    pci_bus has already been destroyed at that point, accesses to it result in
    a use-after-free.
    
    One might conclude that driver binding needs to be prevented after
    pci_stop_bus_device() has run.  However it seems risky that pci_slot points
    to pci_bus without holding a reference.  Solely relying on correct ordering
    of driver unbind versus pci_bus destruction is certainly not defensive
    programming.
    
    If pci_slot has a need to access data in pci_bus, it ought to acquire a
    reference.  Amend pci_create_slot() accordingly.  Dennis reports that the
    crash is not reproducible with this change.
    
    Abridged stacktrace:
    
      pcieport 0000:00:07.0: PME: Signaling with IRQ 156
      pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
      pci_bus 0000:20: dev 00, created physical slot 12
      pcieport 0000:00:07.0: pciehp: Slot(12): Card not present
      ...
      pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0
      Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
      CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1
      RIP: 0010:dev_driver_string+0x12/0x40
      pci_destroy_slot
      pciehp_remove
      pcie_port_remove_service
      device_release_driver_internal
      bus_remove_device
      device_del
      device_unregister
      remove_iter
      device_for_each_child
      pcie_portdrv_remove
      pci_device_remove
      device_release_driver_internal
      bus_remove_device
      device_del
      pci_remove_bus_device (recursive invocation)
      pci_remove_bus_device
      pciehp_unconfigure_device
      pciehp_disable_slot
      pciehp_handle_presence_or_link_change
      pciehp_ist
    
    Link: https://lore.kernel.org/r/4bfd4c0e976c1776cd08e76603903b338cf25729.1728579288.git.lukas@wunner.de
    Reported-by: Dennis Wassenberg <Dennis.Wassenberg@secunet.com>
    Closes: https://lore.kernel.org/r/6de4b45ff2b32dd91a805ec02ec8ec73ef411bf6.camel@secunet.com/
    Tested-by: Dennis Wassenberg <Dennis.Wassenberg@secunet.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 147c97ea836016470156832a5658587c8501c725
Author: Raghavendra Rao Ananta <rananta@google.com>
Date:   Tue Nov 19 16:52:29 2024 -0800

    KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status
    
    commit 54bbee190d42166209185d89070c58a343bf514b upstream.
    
    DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates
    to true if any counter's global enable (PMCR_EL0.E), overflow flag
    (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1.
    Of note, this does not require a counter to be enabled
    (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow.
    
    Align kvm_pmu_overflow_status() with the reality of the architecture
    and stop using PMCNTENSET_EL0 as part of the overflow condition. The
    bug was discovered while running an SBSA PMU test [*], which only sets
    PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt.
    
    Cc: stable@vger.kernel.org
    Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register")
    Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating_system/test_pmu001.c
    Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
    [ oliver: massaged changelog ]
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 488d3036964d0507ced6517d56933abd9dd9a1ce
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Nov 17 16:57:54 2024 +0000

    KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR
    
    commit d561491ba927cb5634094ff311795e9d618e9b86 upstream.
    
    Make sure we filter out non-LPI invalidation when handling writes
    to GICR_INVLPIR.
    
    Fixes: 4645d11f4a553 ("KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation")
    Reported-by: Alexander Potapenko <glider@google.com>
    Tested-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20241117165757.247686-2-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2256aa49e63ac5e1ee600faf2f23e78fb338006
Author: Gautam Menghani <gautam@linux.ibm.com>
Date:   Fri Nov 8 15:18:37 2024 +0530

    powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector
    
    commit 44e5d21e6d3fd2a1fed7f0327cf72e99397e2eaf upstream.
    
    As per the kernel documentation[1], hardlockup detector should
    be disabled in KVM guests as it may give false positives. On
    PPC, hardlockup detector is enabled inside KVM guests because
    disable_hardlockup_detector() is marked as early_initcall and it
    relies on kvm_guest static key (is_kvm_guest()) which is initialized
    later during boot by check_kvm_guest(), which is a core_initcall.
    check_kvm_guest() is also called in pSeries_smp_probe(), which is called
    before initcalls, but it is skipped if KVM guest does not have doorbell
    support or if the guest is launched with SMT=1.
    
    Call check_kvm_guest() in disable_hardlockup_detector() so that
    is_kvm_guest() check goes through fine and hardlockup detector can be
    disabled inside the KVM guest.
    
    [1]: Documentation/admin-guide/sysctl/kernel.rst
    
    Fixes: 633c8e9800f3 ("powerpc/pseries: Enable hardlockup watchdog for PowerVM partitions")
    Cc: stable@vger.kernel.org # v5.14+
    Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241108094839.33084-1-gautam@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3286d64d915e9bfba054e23c4e3a3adcabb41b1
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Oct 10 11:23:06 2024 -0700

    KVM: x86/mmu: Skip the "try unsync" path iff the old SPTE was a leaf SPTE
    
    commit 2867eb782cf7f64c2ac427596133b6f9c3f64b7a upstream.
    
    Apply make_spte()'s optimization to skip trying to unsync shadow pages if
    and only if the old SPTE was a leaf SPTE, as non-leaf SPTEs in direct MMUs
    are always writable, i.e. could trigger a false positive and incorrectly
    lead to KVM creating a SPTE without write-protecting or marking shadow
    pages unsync.
    
    This bug only affects the TDP MMU, as the shadow MMU only overwrites a
    shadow-present SPTE when synchronizing SPTEs (and only 4KiB SPTEs can be
    unsync).  Specifically, mmu_set_spte() drops any non-leaf SPTEs *before*
    calling make_spte(), whereas the TDP MMU can do a direct replacement of a
    page table with the leaf SPTE.
    
    Opportunistically update the comment to explain why skipping the unsync
    stuff is safe, as opposed to simply saying "it's someone else's problem".
    
    Cc: stable@vger.kernel.org
    Tested-by: Alex Bennée <alex.bennee@linaro.org>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Message-ID: <20241010182427.1434605-5-seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d3d3513d44e0c551faecf155721c7166223080a
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Oct 16 17:00:42 2024 -0700

    crypto: x86/aegis128 - access 32-bit arguments as 32-bit
    
    commit 3b2f2d22fb424e9bebda4dbf6676cbfc7f9f62cd upstream.
    
    Fix the AEGIS assembly code to access 'unsigned int' arguments as 32-bit
    values instead of 64-bit, since the upper bits of the corresponding
    64-bit registers are not guaranteed to be zero.
    
    Note: there haven't been any reports of this bug actually causing
    incorrect behavior.  Neither gcc nor clang guarantee zero-extension to
    64 bits, but zero-extension is likely to happen in practice because most
    instructions that operate on 32-bit registers zero-extend to 64 bits.
    
    Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
    Cc: stable@vger.kernel.org
    Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d54a6d066ad7c6c49a4c1989d68699fce30960a5
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Oct 22 18:59:07 2024 +0300

    perf/x86/intel/pt: Fix buffer full but size is 0 case
    
    commit 5b590160d2cf776b304eb054afafea2bd55e3620 upstream.
    
    If the trace data buffer becomes full, a truncated flag [T] is reported
    in PERF_RECORD_AUX.  In some cases, the size reported is 0, even though
    data must have been added to make the buffer full.
    
    That happens when the buffer fills up from empty to full before the
    Intel PT driver has updated the buffer position.  Then the driver
    calculates the new buffer position before calculating the data size.
    If the old and new positions are the same, the data size is reported
    as 0, even though it is really the whole buffer size.
    
    Fix by detecting when the buffer position is wrapped, and adjust the
    data size calculation accordingly.
    
    Example
    
      Use a very small buffer size (8K) and observe the size of truncated [T]
      data. Before the fix, it is possible to see records of 0 size.
    
      Before:
    
        $ perf record -m,8K -e intel_pt// uname
        Linux
        [ perf record: Woken up 2 times to write data ]
        [ perf record: Captured and wrote 0.105 MB perf.data ]
        $ perf script -D --no-itrace | grep AUX | grep -F '[T]'
        Warning:
        AUX data lost 2 times out of 3!
    
        5 19462712368111 0x19710 [0x40]: PERF_RECORD_AUX offset: 0 size: 0 flags: 0x1 [T]
        5 19462712700046 0x19ba8 [0x40]: PERF_RECORD_AUX offset: 0x170 size: 0xe90 flags: 0x1 [T]
    
     After:
    
        $ perf record -m,8K -e intel_pt// uname
        Linux
        [ perf record: Woken up 3 times to write data ]
        [ perf record: Captured and wrote 0.040 MB perf.data ]
        $ perf script -D --no-itrace | grep AUX | grep -F '[T]'
        Warning:
        AUX data lost 2 times out of 3!
    
        1 113720802995 0x4948 [0x40]: PERF_RECORD_AUX offset: 0 size: 0x2000 flags: 0x1 [T]
        1 113720979812 0x6b10 [0x40]: PERF_RECORD_AUX offset: 0x2000 size: 0x2000 flags: 0x1 [T]
    
    Fixes: 52ca9ced3f70 ("perf/x86/intel/pt: Add Intel PT PMU driver")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20241022155920.17511-2-adrian.hunter@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 687c5f18b0ac862b7774bfcdfe9b13a2234420aa
Author: Qiu-ji Chen <chenqiuji666@gmail.com>
Date:   Mon Sep 30 18:12:16 2024 +0800

    ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()
    
    commit 1157733344651ca505e259d6554591ff156922fa upstream.
    
    An atomicity violation occurs when the validity of the variables
    da7219->clk_src and da7219->mclk_rate is being assessed. Since the entire
    assessment is not protected by a lock, the da7219 variable might still be
    in flux during the assessment, rendering this check invalid.
    
    To fix this issue, we recommend adding a lock before the block
    if ((da7219->clk_src == clk_id) && (da7219->mclk_rate == freq)) so that
    the legitimacy check for da7219->clk_src and da7219->mclk_rate is
    protected by the lock, ensuring the validity of the check.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations.
    
    Fixes: 6d817c0e9fd7 ("ASoC: codecs: Add da7219 codec driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com>
    Link: https://patch.msgid.link/20240930101216.23723-1-chenqiuji666@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b10ab1fd2a776b6c2db9b394aeda790bf5d4ceae
Author: Ilya Zverev <ilya@zverev.info>
Date:   Wed Nov 27 15:44:20 2024 +0200

    ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5 21MES00B00
    
    commit b682aa788e5f9f1ddacdfbb453e49fd3f4e83721 upstream.
    
    New ThinkPads need new quirk entries. Ilya has tested this one.
    Laptop product id is 21MES00B00, though the shorthand 21ME works.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219533
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilya Zverev <ilya@zverev.info>
    Link: https://patch.msgid.link/20241127134420.14471-1-ilya@zverev.info
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c356fc32a4480a2c0e537a05f2a8617633ddad0
Author: Artem Sadovnikov <ancowi69@gmail.com>
Date:   Sat Oct 5 10:06:57 2024 +0000

    jfs: xattr: check invalid xattr size more strictly
    
    commit d9f9d96136cba8fedd647d2c024342ce090133c2 upstream.
    
    Commit 7c55b78818cf ("jfs: xattr: fix buffer overflow for invalid xattr")
    also addresses this issue but it only fixes it for positive values, while
    ea_size is an integer type and can take negative values, e.g. in case of
    a corrupted filesystem. This still breaks validation and would overflow
    because of implicit conversion from int to size_t in print_hex_dump().
    
    Fix this issue by clamping the ea_size value instead.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Artem Sadovnikov <ancowi69@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e99f7c2c160bf53f1ce7188c80e5fee6d88c706f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Oct 23 00:25:37 2024 -0400

    ext4: fix FS_IOC_GETFSMAP handling
    
    commit 4a622e4d477bb12ad5ed4abbc7ad1365de1fa347 upstream.
    
    The original implementation ext4's FS_IOC_GETFSMAP handling only
    worked when the range of queried blocks included at least one free
    (unallocated) block range.  This is because how the metadata blocks
    were emitted was as a side effect of ext4_mballoc_query_range()
    calling ext4_getfsmap_datadev_helper(), and that function was only
    called when a free block range was identified.  As a result, this
    caused generic/365 to fail.
    
    Fix this by creating a new function ext4_getfsmap_meta_helper() which
    gets called so that blocks before the first free block range in a
    block group can get properly reported.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a486ba40e2e73459b26932665962968a0c8c3035
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Thu Oct 3 21:53:37 2024 +0900

    ext4: supress data-race warnings in ext4_free_inodes_{count,set}()
    
    commit 902cc179c931a033cd7f4242353aa2733bf8524c upstream.
    
    find_group_other() and find_group_orlov() read *_lo, *_hi with
    ext4_free_inodes_count without additional locking. This can cause
    data-race warning, but since the lock is held for most writes and free
    inodes value is generally not a problem even if it is incorrect, it is
    more appropriate to use READ_ONCE()/WRITE_ONCE() than to add locking.
    
    ==================================================================
    BUG: KCSAN: data-race in ext4_free_inodes_count / ext4_free_inodes_set
    
    write to 0xffff88810404300e of 2 bytes by task 6254 on cpu 1:
     ext4_free_inodes_set+0x1f/0x80 fs/ext4/super.c:405
     __ext4_new_inode+0x15ca/0x2200 fs/ext4/ialloc.c:1216
     ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391
     vfs_symlink+0xca/0x1d0 fs/namei.c:4615
     do_symlinkat+0xe3/0x340 fs/namei.c:4641
     __do_sys_symlinkat fs/namei.c:4657 [inline]
     __se_sys_symlinkat fs/namei.c:4654 [inline]
     __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654
     x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    read to 0xffff88810404300e of 2 bytes by task 6257 on cpu 0:
     ext4_free_inodes_count+0x1c/0x80 fs/ext4/super.c:349
     find_group_other fs/ext4/ialloc.c:594 [inline]
     __ext4_new_inode+0x6ec/0x2200 fs/ext4/ialloc.c:1017
     ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391
     vfs_symlink+0xca/0x1d0 fs/namei.c:4615
     do_symlinkat+0xe3/0x340 fs/namei.c:4641
     __do_sys_symlinkat fs/namei.c:4657 [inline]
     __se_sys_symlinkat fs/namei.c:4654 [inline]
     __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654
     x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://patch.msgid.link/20241003125337.47283-1-aha310510@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78e9af68a7a11e5367b9943e3e6fd0b82b7c01a8
Author: Manikanta Mylavarapu <quic_mmanikan@quicinc.com>
Date:   Wed Oct 16 20:18:52 2024 +0530

    soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()
    
    commit 128fdbf36cddc2a901c4889ba1c89fa9f2643f2c upstream.
    
    In success case, the revision holds a non-null pointer. The current
    logic incorrectly returns an error for a non-null pointer, whereas
    it should return an error for a null pointer.
    
    The socinfo driver for IPQ9574 and IPQ5332 is currently broken,
    resulting in the following error message
    qcom-socinfo qcom-socinfo: probe with driver qcom-socinfo failed with
    error -12
    
    Add a null check for the revision to ensure it returns an error only in
    failure case (null pointer).
    
    Fixes: e694d2b5c58b ("soc: qcom: Add check devm_kasprintf() returned value")
    Signed-off-by: Manikanta Mylavarapu <quic_mmanikan@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20241016144852.2888679-1-quic_mmanikan@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f584f211c04db189ab07638df60d81c87aa5c8ad
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Oct 26 16:36:15 2024 +0200

    ASoC: Intel: sst: Fix used of uninitialized ctx to log an error
    
    commit c1895ba181e560144601fafe46aeedbafdf4dbc4 upstream.
    
    Fix the new "LPE0F28" code path using the uninitialized ctx variable
    to log an error.
    
    Fixes: 6668610b4d8c ("ASoC: Intel: sst: Support LPE0F28 ACPI HID")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202410261106.EBx49ssy-lkp@intel.com/
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patch.msgid.link/20241026143615.171821-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed753a3bd904ad17b4cce490f67981d87ec141c8
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Jun 12 16:31:46 2023 +0100

    dma: allow dma_get_cache_alignment() to be overridden by the arch code
    
    commit 8c57da28dc3df4e091474a004b5596c9b88a3be0 upstream.
    
    On arm64, ARCH_DMA_MINALIGN is larger than most cache line size
    configurations deployed.  Allow an architecture to override
    dma_get_cache_alignment() in order to return a run-time probed value (e.g.
    cache_line_size()).
    
    Link: https://lkml.kernel.org/r/20230612153201.554742-3-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Tested-by: Isaac J. Manjarres <isaacmanjarres@google.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Alasdair Kergon <agk@redhat.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Jerry Snitselaar <jsnitsel@redhat.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Logan Gunthorpe <logang@deltatee.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Mike Snitzer <snitzer@kernel.org>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Saravana Kannan <saravanak@google.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e859e08be57d8752039dd70a6b3b0ce92a56f4d
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue Jun 13 16:52:43 2023 +0100

    powerpc: move the ARCH_DMA_MINALIGN definition to asm/cache.h
    
    commit 78615c4ddb73bd4a7f13ec4bab60b974b8fc6faa upstream.
    
    Patch series "Move the ARCH_DMA_MINALIGN definition to asm/cache.h".
    
    The ARCH_KMALLOC_MINALIGN reduction series defines a generic
    ARCH_DMA_MINALIGN in linux/cache.h:
    
    https://lore.kernel.org/r/20230612153201.554742-2-catalin.marinas@arm.com/
    
    Unfortunately, this causes a duplicate definition warning for
    microblaze, powerpc (32-bit only) and sh as these architectures define
    ARCH_DMA_MINALIGN in a different file than asm/cache.h. Move the macro
    to asm/cache.h to avoid this issue and also bring them in line with the
    other architectures.
    
    
    This patch (of 3):
    
    The powerpc architecture defines ARCH_DMA_MINALIGN in asm/page_32.h and
    only if CONFIG_NOT_COHERENT_CACHE is enabled (32-bit platforms only).
    Move this macro to asm/cache.h to allow a generic ARCH_DMA_MINALIGN
    definition in linux/cache.h without redefine errors/warnings.
    
    Link: https://lkml.kernel.org/r/20230613155245.1228274-1-catalin.marinas@arm.com
    Link: https://lkml.kernel.org/r/20230613155245.1228274-2-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202306131053.1ybvRRhO-lkp@intel.com/
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Michal Simek <monstr@monstr.eu>
    Cc: Rich Felker <dalias@libc.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d52b86bd5a9abcc654fba7780b40bc9e7b0fb44
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Mon Jun 12 16:31:45 2023 +0100

    mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN
    
    commit 4ab5f8ec7d71aea5fe13a48248242130f84ac6bb upstream.
    
    Patch series "mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8", v7.
    
    A series reducing the kmalloc() minimum alignment on arm64 to 8 (from
    128).
    
    
    This patch (of 17):
    
    In preparation for supporting a kmalloc() minimum alignment smaller than
    the arch DMA alignment, decouple the two definitions.  This requires that
    either the kmalloc() caches are aligned to a (run-time) cache-line size or
    the DMA API bounces unaligned kmalloc() allocations.  Subsequent patches
    will implement both options.
    
    After this patch, ARCH_DMA_MINALIGN is expected to be used in static
    alignment annotations and defined by an architecture to be the maximum
    alignment for all supported configurations/SoCs in a single Image.
    Architectures opting in to a smaller ARCH_KMALLOC_MINALIGN will need to
    define its value in the arch headers.
    
    Since ARCH_DMA_MINALIGN is now always defined, adjust the #ifdef in
    dma_get_cache_alignment() so that there is no change for architectures not
    requiring a minimum DMA alignment.
    
    Link: https://lkml.kernel.org/r/20230612153201.554742-1-catalin.marinas@arm.com
    Link: https://lkml.kernel.org/r/20230612153201.554742-2-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Tested-by: Isaac J. Manjarres <isaacmanjarres@google.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Alasdair Kergon <agk@redhat.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Mike Snitzer <snitzer@kernel.org>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Saravana Kannan <saravanak@google.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Jerry Snitselaar <jsnitsel@redhat.com>
    Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95a4d701e2dc76e1343dc5a53b77b7f727ab33e7
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Dec 2 16:16:22 2024 +0800

    arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled
    
    [ Upstream commit 09d385679487c58f0859c1ad4f404ba3df2f8830 ]
    
    USB 3.0 on xhci1 is not used, as the controller shares the same PHY as
    pcie1. The latter is enabled to support the M.2 PCIe WLAN card on this
    design.
    
    Mark USB 3.0 as disabled on this controller using the
    "mediatek,u3p-dis-msk" property.
    
    Reported-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> #KernelCI
    Closes: https://lore.kernel.org/all/9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano/
    Fixes: b6267a396e1c ("arm64: dts: mediatek: cherry: Enable T-PHYs and USB XHCI controllers")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240731034411.371178-2-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdbef2d0e2390828b3efd052120d8b3d293b4f66
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon Dec 2 16:16:21 2024 +0800

    Revert "arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled"
    
    This reverts commit edca00ad79aa1dfd1b88ace1df1e9dfa21a3026f.
    
    The hunk was applied to the wrong device node when the commit was
    backported to the 6.1 stable branch.
    
    Revert it to re-do the backport correctly.
    
    Reported-by: Koichiro Den <koichiro.den@canonical.com>
    Closes: https://lore.kernel.org/stable/6itvivhxbjlpky5hn6x2hmc3kzz4regcvmsk226t6ippjad7yk@26xug5lrdqdw/
    Fixes: edca00ad79aa ("arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 920a369a9f014f10ec282fd298d0666129379f1b
Author: Benoît Sevens <bsevens@google.com>
Date:   Wed Nov 20 12:41:44 2024 +0000

    ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices
    
    commit b909df18ce2a998afef81d58bbd1a05dc0788c40 upstream.
    
    A bogus device can provide a bNumConfigurations value that exceeds the
    initial value used in usb_get_configuration for allocating dev->config.
    
    This can lead to out-of-bounds accesses later, e.g. in
    usb_destroy_configuration.
    
    Signed-off-by: Benoît Sevens <bsevens@google.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@kernel.org
    Link: https://patch.msgid.link/20241120124144.3814457-1-bsevens@google.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75fa2d8b3c0175b519c99ace54ab8474cfd0077e
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Jan 17 16:04:17 2024 +0100

    mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
    
    commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 upstream.
    
    When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
    failing to attach the region to an ACL group, we hit a NULL pointer
    dereference upon 'region->group->tcam' [1].
    
    Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().
    
    [1]
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    [...]
    RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
    [...]
    Call Trace:
     mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
     mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
     mlxsw_sp_acl_rule_add+0x47/0x240
     mlxsw_sp_flower_replace+0x1a9/0x1d0
     tc_setup_cb_add+0xdc/0x1c0
     fl_hw_replace_filter+0x146/0x1f0
     fl_change+0xc17/0x1360
     tc_new_tfilter+0x472/0xb90
     rtnetlink_rcv_msg+0x313/0x3b0
     netlink_rcv_skb+0x58/0x100
     netlink_unicast+0x244/0x390
     netlink_sendmsg+0x1e4/0x440
     ____sys_sendmsg+0x164/0x260
     ___sys_sendmsg+0x9a/0xe0
     __sys_sendmsg+0x7a/0xc0
     do_syscall_64+0x40/0xe0
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ For the function mlxsw_sp_acl_to_tcam() is not exist in 6.1.y, pick
    mlxsw_sp_acl_to_tcam() from commit 74cbc3c03c828ccf265a72f9bcb5aee906978744 ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c81154a308f1aba3a0c13b59aa4191de4f2856fa
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Mon Jul 8 12:33:34 2024 -0700

    perf/x86/intel: Hide Topdown metrics events if the feature is not enumerated
    
    commit 556a7c039a52c21da33eaae9269984a1ef59189b upstream.
    
    The below error is observed on Ice Lake VM.
    
    $ perf stat
    Error:
    The sys_perf_event_open() syscall returned with 22 (Invalid argument)
    for event (slots).
    /bin/dmesg | grep -i perf may provide additional information.
    
    In a virtualization env, the Topdown metrics and the slots event haven't
    been supported yet. The guest CPUID doesn't enumerate them. However, the
    current kernel unconditionally exposes the slots event and the Topdown
    metrics events to sysfs, which misleads the perf tool and triggers the
    error.
    
    Hide the perf-metrics topdown events and the slots event if the
    perf-metrics feature is not enumerated.
    
    The big core of a hybrid platform can also supports the perf-metrics
    feature. Fix the hybrid platform as well.
    
    Closes: https://lore.kernel.org/lkml/CAM9d7cj8z+ryyzUHR+P1Dcpot2jjW+Qcc4CPQpfafTXN=LEU0Q@mail.gmail.com/
    Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
    Link: https://lkml.kernel.org/r/20240708193336.1192217-2-kan.liang@linux.intel.com
    Signed-off-by: Hagar Hemdan <hagarhem@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 945559be6e282a812dc48f7bcd5adc60901ea4a0
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>
    [Xiangyu: BP to fix CVE-2024-35956, due to 6.1 btrfs_subvolume_release_metadata()
    defined in ctree.h, modified the header file name from root-tree.h to ctree.h]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 224fd631c41b81697aa622d38615bfbf446b91cf
Author: Zqiang <qiang.zhang1211@gmail.com>
Date:   Wed Jul 10 12:45:42 2024 +0800

    rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()
    
    commit fd70e9f1d85f5323096ad313ba73f5fe3d15ea41 upstream.
    
    For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is
    defined as NR_CPUS instead of the number of possible cpus, this
    will cause the following system panic:
    
    smpboot: Allowing 4 CPUs, 0 hotplug CPUs
    ...
    setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1
    ...
    BUG: unable to handle page fault for address: ffffffff9911c8c8
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W
    6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6
    RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0
    RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082
    CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0
    Call Trace:
    <TASK>
    ? __die+0x23/0x80
    ? page_fault_oops+0xa4/0x180
    ? exc_page_fault+0x152/0x180
    ? asm_exc_page_fault+0x26/0x40
    ? rcu_tasks_need_gpcb+0x25d/0x2c0
    ? __pfx_rcu_tasks_kthread+0x40/0x40
    rcu_tasks_one_gp+0x69/0x180
    rcu_tasks_kthread+0x94/0xc0
    kthread+0xe8/0x140
    ? __pfx_kthread+0x40/0x40
    ret_from_fork+0x34/0x80
    ? __pfx_kthread+0x40/0x40
    ret_from_fork_asm+0x1b/0x80
    </TASK>
    
    Considering that there may be holes in the CPU numbers, use the
    maximum possible cpu number, instead of nr_cpu_ids, for configuring
    enqueue and dequeue limits.
    
    [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]
    
    Closes: https://lore.kernel.org/linux-input/CALMA0xaTSMN+p4xUXkzrtR5r6k7hgoswcaXx7baR_z9r5jjskw@mail.gmail.com/T/#u
    Reported-by: Zhixu Liu <zhixu.liu@gmail.com>
    Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
    Signed-off-by: Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: BP to fix CVE:CVE-2024-49926, minor conflict resolution]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db1d7e1794fed62ee16d6a72a85997bb069e2e27
Author: Alex Hung <alex.hung@amd.com>
Date:   Thu Jun 20 20:23:41 2024 -0600

    drm/amd/display: Check phantom_stream before it is used
    
    commit 3718a619a8c0a53152e76bb6769b6c414e1e83f4 upstream.
    
    dcn32_enable_phantom_stream can return null, so returned value
    must be checked before used.
    
    This fixes 1 NULL_RETURNS issue reported by Coverity.
    
    Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: BP to fix CVE: CVE-2024-49897, modified the source path]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8a24767899c86f4c5f1e4d3b2608942d054900f
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Jul 31 13:09:28 2024 +0530

    drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func
    
    commit 62ed6f0f198da04e884062264df308277628004f upstream.
    
    This commit adds a null check for the set_output_gamma function pointer
    in the dcn20_set_output_transfer_func function. Previously,
    set_output_gamma was being checked for null at line 1030, but then it
    was being dereferenced without any null check at line 1048. This could
    potentially lead to a null pointer dereference error if set_output_gamma
    is null.
    
    To fix this, we now ensure that set_output_gamma is not null before
    dereferencing it. We do this by adding a null check for set_output_gamma
    before the call to set_output_gamma at line 1048.
    
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Alex Hung <alex.hung@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d94d9cbd9fec7344d230c4f7b781826f7799c60
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Mon Jul 22 16:44:40 2024 +0530

    drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw
    
    commit c395fd47d1565bd67671f45cca281b3acc2c31ef upstream.
    
    This commit addresses a potential null pointer dereference issue in the
    `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is
    null.
    
    The fix adds a check to ensure `dc->clk_mgr` is not null before
    accessing its functions. This prevents a potential null pointer
    dereference.
    
    Reported by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)
    
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Alex Hung <alex.hung@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: BP to fix CVE: CVE-2024-49915, modified the source path]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23cb6139543580dc36743586ca86fbb3f7ab2c9d
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Mon Jul 22 16:21:19 2024 +0530

    drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw
    
    commit cba7fec864172dadd953daefdd26e01742b71a6a upstream.
    
    This commit addresses a potential null pointer dereference issue in the
    `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or
    `dc->clk_mgr->funcs` is null.
    
    The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is
    not null before accessing its functions. This prevents a potential null
    pointer dereference.
    
    Reported by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)
    
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Alex Hung <alex.hung@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: BP to fix CVE: CVE-2024-49917, modified the source path]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbc6fc9cfcde151ff5eadaefdc6155f99579384f
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Sun Aug 25 19:17:09 2024 +0300

    wifi: iwlwifi: mvm: avoid NULL pointer dereference
    
    commit 557a6cd847645e667f3b362560bd7e7c09aac284 upstream.
    
    iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
    pointer is not NULL.
    It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
    dereferencing the ieee80211_sta pointer.
    If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
    pointer.
    Fix this by checking the sta pointer before retrieving the mvmsta
    from it. If sta is not NULL, then mvmsta isn't either.
    
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://patch.msgid.link/20240825191257.880921ce23b7.I340052d70ab6d3410724ce955eb00da10e08188f@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c823e4027dd1d6e88c31028dec13dd19bc7b02d
Author: Jammy Huang <jammy_huang@aspeedtech.com>
Date:   Wed Jul 19 06:33:18 2023 +0000

    media: aspeed: Fix memory overwrite if timing is 1600x900
    
    commit c281355068bc258fd619c5aefd978595bede7bfe upstream.
    
    When capturing 1600x900, system could crash when system memory usage is
    tight.
    
    The way to reproduce this issue:
    1. Use 1600x900 to display on host
    2. Mount ISO through 'Virtual media' on OpenBMC's web
    3. Run script as below on host to do sha continuously
      #!/bin/bash
      while [ [1] ];
      do
            find /media -type f -printf '"%h/%f"\n' | xargs sha256sum
      done
    4. Open KVM on OpenBMC's web
    
    The size of macro block captured is 8x8. Therefore, we should make sure
    the height of src-buf is 8 aligned to fix this issue.
    
    Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a04ce0bc92c831a00070c1557be5824cdbdb892
Author: Vitalii Mordan <mordan@ispras.ru>
Date:   Fri Nov 15 02:03:10 2024 +0300

    usb: ehci-spear: fix call balance of sehci clk handling routines
    
    commit 40c974826734836402abfd44efbf04f63a2cc1c1 upstream.
    
    If the clock sehci->clk was not enabled in spear_ehci_hcd_drv_probe,
    it should not be disabled in any path.
    
    Conversely, if it was enabled in spear_ehci_hcd_drv_probe, it must be disabled
    in all error paths to ensure proper cleanup.
    
    Found by Linux Verification Center (linuxtesting.org) with Klever.
    
    Fixes: 7675d6ba436f ("USB: EHCI: make ehci-spear a separate driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Vitalii Mordan <mordan@ispras.ru>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20241114230310.432213-1-mordan@ispras.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da13ade87a12dd58829278bc816a61bea06a56a9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Nov 25 15:46:16 2024 +0100

    ALSA: usb-audio: Fix out of bounds reads when finding clock sources
    
    commit a3dd4d63eeb452cfb064a13862fb376ab108f6a6 upstream.
    
    The current USB-audio driver code doesn't check bLength of each
    descriptor at traversing for clock descriptors.  That is, when a
    device provides a bogus descriptor with a shorter bLength, the driver
    might hit out-of-bounds reads.
    
    For addressing it, this patch adds sanity checks to the validator
    functions for the clock descriptor traversal.  When the descriptor
    length is shorter than expected, it's skipped in the loop.
    
    For the clock source and clock multiplier descriptors, we can just
    check bLength against the sizeof() of each descriptor type.
    OTOH, the clock selector descriptor of UAC2 and UAC3 has an array
    of bNrInPins elements and two more fields at its tail, hence those
    have to be checked in addition to the sizeof() check.
    
    Reported-by: Benoît Sevens <bsevens@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/20241121140613.3651-1-bsevens@google.com
    Link: https://patch.msgid.link/20241125144629.20757-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fc0996d2fefe61219375fd650601724b8cf2d30
Author: Qiu-ji Chen <chenqiuji666@gmail.com>
Date:   Tue Nov 5 21:09:19 2024 +0800

    xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
    
    commit afc545da381ba0c651b2658966ac737032676f01 upstream.
    
    This patch fixes an issue in the function xenbus_dev_probe(). In the
    xenbus_dev_probe() function, within the if (err) branch at line 313, the
    program incorrectly returns err directly without releasing the resources
    allocated by err = drv->probe(dev, id). As the return value is non-zero,
    the upper layers assume the processing logic has failed. However, the probe
    operation was performed earlier without a corresponding remove operation.
    Since the probe actually allocates resources, failing to perform the remove
    operation could lead to problems.
    
    To fix this issue, we followed the resource release logic of the
    xenbus_dev_remove() function by adding a new block fail_remove before the
    fail_put block. After entering the branch if (err) at line 313, the
    function will use a goto statement to jump to the fail_remove block,
    ensuring that the previously acquired resources are correctly released,
    thus preventing the reference count leak.
    
    This bug was identified by an experimental static analysis tool developed
    by our team. The tool specializes in analyzing reference count operations
    and detecting potential issues where resources are not properly managed.
    In this case, the tool flagged the missing release operation as a
    potential problem, which led to the development of this patch.
    
    Fixes: 4bac07c993d0 ("xen: add the Xenbus sysfs and virtual device hotplug driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Message-ID: <20241105130919.4621-1-chenqiuji666@gmail.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1e3efe783365db59da88f08a2e0bfe1cc95b143
Author: lei lu <llfamsec@gmail.com>
Date:   Mon Jun 3 17:46:08 2024 +0800

    xfs: add bounds checking to xlog_recover_process_data
    
    commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream.
    
    There is a lack of verification of the space occupied by fixed members
    of xlog_op_header in the xlog_recover_process_data.
    
    We can create a crafted image to trigger an out of bounds read by
    following these steps:
        1) Mount an image of xfs, and do some file operations to leave records
        2) Before umounting, copy the image for subsequent steps to simulate
           abnormal exit. Because umount will ensure that tail_blk and
           head_blk are the same, which will result in the inability to enter
           xlog_recover_process_data
        3) Write a tool to parse and modify the copied image in step 2
        4) Make the end of the xlog_op_header entries only 1 byte away from
           xlog_rec_header->h_size
        5) xlog_rec_header->h_num_logops++
        6) Modify xlog_rec_header->h_crc
    
    Fix:
    Add a check to make sure there is sufficient space to access fixed members
    of xlog_op_header.
    
    Signed-off-by: lei lu <llfamsec@gmail.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5873aa7f814754085d418848b2089ef406a02dd0
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Fri Jul 26 16:15:07 2024 -0700

    scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths
    
    commit 2be1d4f11944cd6283cb97268b3e17c4424945ca upstream.
    
    When the HBA is undergoing a reset or is handling an errata event, NULL ptr
    dereference crashes may occur in routines such as
    lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
    lpfc_abort_handler().
    
    Add NULL ptr checks before dereferencing hdwq pointers that may have been
    freed due to operations colliding with a reset or errata event handler.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240726231512.92867-4-justintee8345@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [Xiangyu: BP to fix CVE: CVE-2024-49891, no test_bit() conflict resolution]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 386613a44b858304a88529ade2ccc1e079a5fc56
Author: lei lu <llfamsec@gmail.com>
Date:   Fri Aug 23 21:39:44 2024 +0800

    ntfs3: Add bounds checking to mi_enum_attr()
    
    commit 556bdf27c2dd5c74a9caacbe524b943a6cd42d99 upstream.
    
    Added bounds checking to make sure that every attr don't stray beyond
    valid memory region.
    
    Signed-off-by: lei lu <llfamsec@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e99faa97359654b6e4e769246c72cf50a57e05b2
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:14:31 2024 +0300

    fs/ntfs3: Fixed overflow check in mi_enum_attr()
    
    commit 652cfeb43d6b9aba5c7c4902bed7a7340df131fb upstream.
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1403991a40b94438a2acc749bf05c117abdb34f9
Author: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Date:   Thu Jul 18 22:17:04 2024 +0800

    mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()
    
    commit a8bd68e4329f9a0ad1b878733e0f80be6a971649 upstream.
    
    When mtk-cmdq unbinds, a WARN_ON message with condition
    pm_runtime_get_sync() < 0 occurs.
    
    According to the call tracei below:
      cmdq_mbox_shutdown
      mbox_free_channel
      mbox_controller_unregister
      __devm_mbox_controller_unregister
      ...
    
    The root cause can be deduced to be calling pm_runtime_get_sync() after
    calling pm_runtime_disable() as observed below:
    1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe()
       to bind the cmdq device to the mbox_controller, so
       devm_mbox_controller_unregister() will automatically unregister
       the device bound to the mailbox controller when the device-managed
       resource is removed. That means devm_mbox_controller_unregister()
       and cmdq_mbox_shoutdown() will be called after cmdq_remove().
    2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after
       devm_mbox_controller_register(), so that devm_pm_runtime_disable()
       will be called after cmdq_remove(), but before
       devm_mbox_controller_unregister().
    
    To fix this problem, cmdq_probe() needs to move
    devm_mbox_controller_register() after devm_pm_runtime_enable() to make
    devm_pm_runtime_disable() be called after
    devm_mbox_controller_unregister().
    
    Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
    Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f3cee7f3e2ecf3ef825c0be11ae04fbf9011b49
Author: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Date:   Wed Nov 27 16:52:25 2024 +0530

    ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry
    
    [ Upstream commit 4095cf872084ecfdfdb0e681f3e9ff9745acfa75 ]
    
    Add condition check to register ACP PDM sound card by reading
    _WOV acpi entry.
    
    Fixes: 5426f506b584 ("ASoC: amd: Add support for enabling DMIC on acp6x via _DSD")
    
    Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
    Link: https://patch.msgid.link/20241127112227.227106-1-venkataprasad.potturu@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ae27e61d15e2444bda15608a543d9f4138966ca
Author: chao liu <liuzgyid@outlook.com>
Date:   Tue Jun 27 10:03:16 2023 +0800

    apparmor: fix 'Do simple duplicate message elimination'
    
    [ Upstream commit 9b897132424fe76bf6c61f22f9cf12af7f1d1e6a ]
    
    Multiple profiles shared 'ent->caps', so some logs missed.
    
    Fixes: 0ed3b28ab8bf ("AppArmor: mediation of non file objects")
    Signed-off-by: chao liu <liuzgyid@outlook.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5db93cdacf04d10f81ee42f1614ef01a6cb3f55f
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Nov 14 15:21:09 2024 +0800

    ALSA: hda/realtek: Update ALC256 depop procedure
    
    [ Upstream commit cc3d0b5dd989d3238d456f9fd385946379a9c13d ]
    
    Old procedure has a chance to meet Headphone no output.
    
    Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function")
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/463c5f93715d4714967041a0a8cec28e@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6adeb401fd17a89ce4eb87adb3db2e6bbc6b823a
Author: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Date:   Mon Nov 4 19:40:59 2024 +0000

    counter: ti-ecap-capture: Add check for clk_enable()
    
    [ Upstream commit 1437d9f1c56fce9c24e566508bce1d218dd5497a ]
    
    Add check for the return value of clk_enable() in order to catch the
    potential exception.
    
    Fixes: 4e2f42aa00b6 ("counter: ti-ecap-capture: capture driver support for ECAP")
    Reviewed-by: Julien Panis <jpanis@baylibre.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://lore.kernel.org/r/20241104194059.47924-1-jiashengjiangcool@gmail.com
    Signed-off-by: William Breathitt Gray <wbg@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb479d737db40c1c2e64ceb08e91aca097078c13
Author: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Date:   Mon Nov 4 19:18:25 2024 +0000

    counter: stm32-timer-cnt: Add check for clk_enable()
    
    [ Upstream commit 842c3755a6bfbfcafa4a1438078d2485a9eb1d87 ]
    
    Add check for the return value of clk_enable() in order to catch the
    potential exception.
    
    Fixes: c5b8425514da ("counter: stm32-timer-cnt: add power management support")
    Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://lore.kernel.org/r/20241104191825.40155-1-jiashengjiangcool@gmail.com
    Signed-off-by: William Breathitt Gray <wbg@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 367f7727ae62791b27b71ace26deb9590e0728b6
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Mon Sep 23 11:55:56 2024 +0800

    misc: apds990x: Fix missing pm_runtime_disable()
    
    [ Upstream commit 3c5d8b819d27012264edd17e6ae7fffda382fe44 ]
    
    The pm_runtime_disable() is missing in probe error path,
    so add it to fix it.
    
    Fixes: 92b1f84d46b2 ("drivers/misc: driver for APDS990X ALS and proximity sensors")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20240923035556.3009105-1-ruanjinjie@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de47d0f430dbf05de8b54573dac6e630ba99d0b1
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Wed Oct 9 22:52:07 2024 +0800

    USB: chaoskey: Fix possible deadlock chaoskey_list_lock
    
    [ Upstream commit d73dc7b182be4238b75278bfae16afb4c5564a58 ]
    
    [Syzbot reported two possible deadlocks]
    The first possible deadlock is:
    WARNING: possible recursive locking detected
    6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted
    --------------------------------------------
    syz-executor363/2651 is trying to acquire lock:
    ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x15d/0x2c0 drivers/usb/misc/chaoskey.c:322
    
    but task is already holding lock:
    ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x7f/0x2c0 drivers/usb/misc/chaoskey.c:299
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(chaoskey_list_lock);
      lock(chaoskey_list_lock);
    
     *** DEADLOCK ***
    
    The second possible deadlock is:
    WARNING: possible circular locking dependency detected
    6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted
    ------------------------------------------------------
    kworker/0:2/804 is trying to acquire lock:
    ffffffff899dadb0 (minor_rwsem){++++}-{3:3}, at: usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186
    
    but task is already holding lock:
    ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_disconnect+0xa8/0x2a0 drivers/usb/misc/chaoskey.c:235
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (chaoskey_list_lock){+.+.}-{3:3}:
           __mutex_lock_common kernel/locking/mutex.c:608 [inline]
           __mutex_lock+0x175/0x9c0 kernel/locking/mutex.c:752
           chaoskey_open+0xdd/0x220 drivers/usb/misc/chaoskey.c:274
           usb_open+0x186/0x220 drivers/usb/core/file.c:47
           chrdev_open+0x237/0x6a0 fs/char_dev.c:414
           do_dentry_open+0x6cb/0x1390 fs/open.c:958
           vfs_open+0x82/0x3f0 fs/open.c:1088
           do_open fs/namei.c:3774 [inline]
           path_openat+0x1e6a/0x2d60 fs/namei.c:3933
           do_filp_open+0x1dc/0x430 fs/namei.c:3960
           do_sys_openat2+0x17a/0x1e0 fs/open.c:1415
           do_sys_open fs/open.c:1430 [inline]
           __do_sys_openat fs/open.c:1446 [inline]
           __se_sys_openat fs/open.c:1441 [inline]
           __x64_sys_openat+0x175/0x210 fs/open.c:1441
           do_syscall_x64 arch/x86/entry/common.c:52 [inline]
           do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    -> #0 (minor_rwsem){++++}-{3:3}:
           check_prev_add kernel/locking/lockdep.c:3161 [inline]
           check_prevs_add kernel/locking/lockdep.c:3280 [inline]
           validate_chain kernel/locking/lockdep.c:3904 [inline]
           __lock_acquire+0x250b/0x3ce0 kernel/locking/lockdep.c:5202
           lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5825
           down_write+0x93/0x200 kernel/locking/rwsem.c:1577
           usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186
           chaoskey_disconnect+0xb7/0x2a0 drivers/usb/misc/chaoskey.c:236
           usb_unbind_interface+0x1e8/0x970 drivers/usb/core/driver.c:461
           device_remove drivers/base/dd.c:569 [inline]
           device_remove+0x122/0x170 drivers/base/dd.c:561
           __device_release_driver drivers/base/dd.c:1273 [inline]
           device_release_driver_internal+0x44a/0x610 drivers/base/dd.c:1296
           bus_remove_device+0x22f/0x420 drivers/base/bus.c:576
           device_del+0x396/0x9f0 drivers/base/core.c:3864
           usb_disable_device+0x36c/0x7f0 drivers/usb/core/message.c:1418
           usb_disconnect+0x2e1/0x920 drivers/usb/core/hub.c:2304
           hub_port_connect drivers/usb/core/hub.c:5361 [inline]
           hub_port_connect_change drivers/usb/core/hub.c:5661 [inline]
           port_event drivers/usb/core/hub.c:5821 [inline]
           hub_event+0x1bed/0x4f40 drivers/usb/core/hub.c:5903
           process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229
           process_scheduled_works kernel/workqueue.c:3310 [inline]
           worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391
           kthread+0x2c1/0x3a0 kernel/kthread.c:389
           ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
           ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(chaoskey_list_lock);
                                   lock(minor_rwsem);
                                   lock(chaoskey_list_lock);
      lock(minor_rwsem);
    
     *** DEADLOCK ***
    [Analysis]
    The first is AA lock, it because wrong logic, it need a unlock.
    The second is AB lock, it needs to rearrange the order of lock usage.
    
    Fixes: 422dc0a4d12d ("USB: chaoskey: fail open after removal")
    Reported-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com
    Reported-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=685e14d04fe35692d3bc
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Tested-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com
    Reported-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com
    Tested-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com
    Tested-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/tencent_84EB865C89862EC22EE94CB3A7C706C59206@qq.com
    Cc: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78e892874ca66967d44bd3a96e2fefaae4ca3755
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Oct 2 15:21:41 2024 +0200

    USB: chaoskey: fail open after removal
    
    [ Upstream commit 422dc0a4d12d0b80dd3aab3fe5943f665ba8f041 ]
    
    chaoskey_open() takes the lock only to increase the
    counter of openings. That means that the mutual exclusion
    with chaoskey_disconnect() cannot prevent an increase
    of the counter and chaoskey_open() returning a success.
    
    If that race is hit, chaoskey_disconnect() will happily
    free all resources associated with the device after
    it has dropped the lock, as it has read the counter
    as zero.
    
    To prevent this race chaoskey_open() has to check
    the presence of the device under the lock.
    However, the current per device lock cannot be used,
    because it is a part of the data structure to be
    freed. Hence an additional global mutex is needed.
    The issue is as old as the driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-by: syzbot+422188bce66e76020e55@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55
    Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)")
    Rule: add
    Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com
    Link: https://lore.kernel.org/r/20241002132201.552578-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfb7f88ed3bec006f11d4b68c576165731270b88
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Sep 24 10:43:45 2024 +0200

    usb: yurex: make waiting on yurex_write interruptible
    
    [ Upstream commit e0aa9614ab0fd35b404e4b16ebe879f9fc152591 ]
    
    The IO yurex_write() needs to wait for in order to have a device
    ready for writing again can take a long time time.
    Consequently the sleep is done in an interruptible state.
    Therefore others waiting for yurex_write() itself to finish should
    use mutex_lock_interruptible.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Fixes: 6bc235a2e24a5 ("USB: add driver for Meywa-Denki & Kayac YUREX")
    Rule: add
    Link: https://lore.kernel.org/stable/20240924084415.300557-1-oneukum%40suse.com
    Link: https://lore.kernel.org/r/20240924084415.300557-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83aa97ef3739d2b1024cfc487d56a4b2319cc7f5
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Thu Sep 19 19:34:03 2024 +0900

    usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()
    
    [ Upstream commit 44feafbaa66ec86232b123bb8437a6a262442025 ]
    
    iowarrior_read() uses the iowarrior dev structure, but does not use any
    lock on the structure. This can cause various bugs including data-races,
    so it is more appropriate to use a mutex lock to safely protect the
    iowarrior dev structure. When using a mutex lock, you should split the
    branch to prevent blocking when the O_NONBLOCK flag is set.
    
    In addition, it is unnecessary to check for NULL on the iowarrior dev
    structure obtained by reading file->private_data. Therefore, it is
    better to remove the check.
    
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Link: https://lore.kernel.org/r/20240919103403.3986-1-aha310510@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2dc98452285d1762f106e77b9ee0dc5b4e4bf242
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Sep 10 20:36:06 2024 +0200

    iio: light: al3010: Fix an error handling path in al3010_probe()
    
    [ Upstream commit a4b7064d34186cf4970fe0333c3b27346cf8f819 ]
    
    If i2c_smbus_write_byte_data() fails in al3010_init(),
    al3010_set_pwr(false) is not called.
    
    In order to avoid such a situation, move the devm_add_action_or_reset()
    witch calls al3010_set_pwr(false) right after a successful
    al3010_set_pwr(true).
    
    Fixes: c36b5195ab70 ("iio: light: add Dyna-Image AL3010 driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://patch.msgid.link/ee5d10a2dd2b70f29772d5df33774d3974a80f30.1725993353.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d338cee86f1d8c22a17752871f526fe43a60f70
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Sun Nov 24 16:40:58 2024 +0100

    ipmr: fix tables suspicious RCU usage
    
    [ Upstream commit fc9c273d6daaa9866f349bbe8cae25c67764c456 ]
    
    Similar to the previous patch, plumb the RCU lock inside
    the ipmr_get_table(), provided a lockless variant and apply
    the latter in the few spots were the lock is already held.
    
    Fixes: 709b46e8d90b ("net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT")
    Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables")
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e656d0565d9058c6cd2d2d2faa608359e19feae
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Sun Nov 24 16:40:57 2024 +0100

    ip6mr: fix tables suspicious RCU usage
    
    [ Upstream commit f1553c9894b4dbeb10a2ab15ab1aa113b3b4047c ]
    
    Several places call ip6mr_get_table() with no RCU nor RTNL lock.
    Add RCU protection inside such helper and provide a lockless variant
    for the few callers that already acquired the relevant lock.
    
    Note that some users additionally reference the table outside the RCU
    lock. That is actually safe as the table deletion can happen only
    after all table accesses are completed.
    
    Fixes: e2d57766e674 ("net: Provide compat support for SIOCGETMIFCNT_IN6 and SIOCGETSGCNT_IN6.")
    Fixes: d7c31cbde4bc ("net: ip6mr: add RTM_GETROUTE netlink op")
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a3c1ad93e6fba67b3a637cfa95a57a6685e4908
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sat Nov 23 09:42:36 2024 -0800

    tcp: Fix use-after-free of nreq in reqsk_timer_handler().
    
    [ Upstream commit c31e72d021db2714df03df6c42855a1db592716c ]
    
    The cited commit replaced inet_csk_reqsk_queue_drop_and_put() with
    __inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler().
    
    Then, oreq should be passed to reqsk_put() instead of req; otherwise
    use-after-free of nreq could happen when reqsk is migrated but the
    retry attempt failed (e.g. due to timeout).
    
    Let's pass oreq to reqsk_put().
    
    Fixes: e8c526f2bdf1 ("tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().")
    Reported-by: Liu Jian <liujian56@huawei.com>
    Closes: https://lore.kernel.org/netdev/1284490f-9525-42ee-b7b8-ccadf6606f6d@huawei.com/
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
    Reviewed-by: Liu Jian <liujian56@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://patch.msgid.link/20241123174236.62438-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7845361d51e910a820054543dc854dea4e6d9e9
Author: Michal Luczaj <mhal@rbox.co>
Date:   Tue Nov 19 14:31:42 2024 +0100

    rxrpc: Improve setsockopt() handling of malformed user input
    
    [ Upstream commit 02020056647017e70509bb58c3096448117099e1 ]
    
    copy_from_sockptr() does not return negative value on error; instead, it
    reports the number of bytes that failed to copy. Since it's deprecated,
    switch to copy_safe_from_sockptr().
    
    Note: Keeping the `optlen != sizeof(unsigned int)` check as
    copy_safe_from_sockptr() by itself would also accept
    optlen > sizeof(unsigned int). Which would allow a more lenient handling
    of inputs.
    
    Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 981d647c6f664871cc75ad424eead207df7dc571
Author: Michal Luczaj <mhal@rbox.co>
Date:   Tue Nov 19 14:31:41 2024 +0100

    llc: Improve setsockopt() handling of malformed user input
    
    [ Upstream commit 1465036b10be4b8b00eb31c879e86de633ad74c1 ]
    
    copy_from_sockptr() is used incorrectly: return value is the number of
    bytes that could not be copied. Since it's deprecated, switch to
    copy_safe_from_sockptr().
    
    Note: Keeping the `optlen != sizeof(int)` check as copy_safe_from_sockptr()
    by itself would also accept optlen > sizeof(int). Which would allow a more
    lenient handling of inputs.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Suggested-by: David Wei <dw@davidwei.uk>
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f688979e42508552e05c72e4f45b828eef01b2c3
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Apr 13 14:24:17 2023 +0800

    crypto: api - Add crypto_clone_tfm
    
    [ Upstream commit 3c3a24cb0ae46c9c45e4ce2272f84f0504831f59 ]
    
    This patch adds the helper crypto_clone_tfm.  The purpose is to
    allocate a tfm object with GFP_ATOMIC.  As we cannot sleep, the
    object has to be cloned from an existing tfm object.
    
    This allows code paths that cannot otherwise allocate a crypto_tfm
    object to do so.  Once a new tfm has been obtained its key could
    then be changed without impacting other users.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 1465036b10be ("llc: Improve setsockopt() handling of malformed user input")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e470d423b0f6ffd3977e74d1d1eef70cc58f18dd
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Apr 13 14:24:15 2023 +0800

    crypto: api - Add crypto_tfm_get
    
    [ Upstream commit ae131f4970f0778f35ed06aeb15bde2fbc1d9619 ]
    
    Add a crypto_tfm_get interface to allow tfm objects to be shared.
    They can still be freed in the usual way.
    
    This should only be done with tfm objects with no keys.  You must
    also not modify the tfm flags in any way once it becomes shared.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 1465036b10be ("llc: Improve setsockopt() handling of malformed user input")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdfc818ffdfeb8266351ed59b6d884056009a095
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Nov 15 10:45:31 2024 -0500

    Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync
    
    [ Upstream commit 0b882940665ca2849386ee459d4331aa2f8c4e7d ]
    
    This fixes the following crash:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353
    Read of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54
    
    CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:93 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x169/0x550 mm/kasan/report.c:488
    q kasan_report+0x143/0x180 mm/kasan/report.c:601
     set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353
     hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328
     process_one_work kernel/workqueue.c:3231 [inline]
     process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
     worker_thread+0x86d/0xd10 kernel/workqueue.c:3389
     kthread+0x2f0/0x390 kernel/kthread.c:389
     ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
     </TASK>
    
    Allocated by task 5247:
     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]
     __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193
     kmalloc_noprof include/linux/slab.h:681 [inline]
     kzalloc_noprof include/linux/slab.h:807 [inline]
     mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269
     mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296
     set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394
     hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712
     hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x221/0x270 net/socket.c:745
     sock_write_iter+0x2dd/0x400 net/socket.c:1160
     new_sync_write fs/read_write.c:497 [inline]
     vfs_write+0xa72/0xc90 fs/read_write.c:590
     ksys_write+0x1a0/0x2c0 fs/read_write.c:643
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 5246:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
     poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
     __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
     kasan_slab_free include/linux/kasan.h:184 [inline]
     slab_free_hook mm/slub.c:2256 [inline]
     slab_free mm/slub.c:4477 [inline]
     kfree+0x149/0x360 mm/slub.c:4598
     settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443
     mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
     __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455
     hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191
     hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]
     hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508
     sock_do_ioctl+0x158/0x460 net/socket.c:1222
     sock_ioctl+0x629/0x8e0 net/socket.c:1341
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Reported-by: syzbot+03d6270b6425df1605bf@syzkaller.appspotmail.com
    Tested-by: syzbot+03d6270b6425df1605bf@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=03d6270b6425df1605bf
    Fixes: 275f3f648702 ("Bluetooth: Fix not checking MGMT cmd pending queue")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be3fa6b04140b1f29593dbd8209c72945c4a42a2
Author: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
Date:   Fri Nov 22 14:45:41 2024 -0800

    bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down
    
    [ Upstream commit 5311598f7f3293683cdc761df71ae3469327332c ]
    
    After successful PCIe AER recovery, FW will reset all resource
    reservations.  If it is IF_UP, the driver will call bnxt_open() and
    all resources will be reserved again.  It it is IF_DOWN, we should
    call bnxt_reserve_rings() so that we can reserve resources including
    RoCE resources to allow RoCE to resume after AER.  Without this
    patch, RoCE fails to resume in this IF_DOWN scenario.
    
    Later, if it becomes IF_UP, bnxt_open() will see that resources have
    been reserved and will not reserve again.
    
    Fixes: fb1e6e562b37 ("bnxt_en: Fix AER recovery.")
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Reviewed-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d339e12588ee8a578dad5fe9c928063326b65d0
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Nov 22 17:13:43 2024 +0000

    net: hsr: fix hsr_init_sk() vs network/transport headers.
    
    [ Upstream commit 9cfb5e7f0ded2bfaabc270ceb5f91d13f0e805b9 ]
    
    Following sequence in hsr_init_sk() is invalid :
    
        skb_reset_mac_header(skb);
        skb_reset_mac_len(skb);
        skb_reset_network_header(skb);
        skb_reset_transport_header(skb);
    
    It is invalid because skb_reset_mac_len() needs the correct
    network header, which should be after the mac header.
    
    This patch moves the skb_reset_network_header()
    and skb_reset_transport_header() before
    the call to dev_hard_header().
    
    As a result skb->mac_len is no longer set to a value
    close to 65535.
    
    Fixes: 48b491a5cc74 ("net: hsr: fix mac_len checks")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: George McCollister <george.mccollister@gmail.com>
    Link: https://patch.msgid.link/20241122171343.897551-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1169cfe66af7a09008dacf5b2a0320921cb9f5cb
Author: Csókás, Bence <csokas.bence@prolan.hu>
Date:   Fri Nov 22 15:13:02 2024 +0100

    spi: atmel-quadspi: Fix register name in verbose logging function
    
    [ Upstream commit 2ac40e6d0ccdd93031f8b1af61b0fe5cdd704923 ]
    
    `atmel_qspi_reg_name()` is used for pretty-printing register offsets
    for verbose logging of register accesses. However, due to a typo
    (likely a copy-paste error), QSPI_RD's offset prints as "MR", the
    name of the previous register. Fix this typo.
    
    Fixes: c528ecfbef04 ("spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses")
    Signed-off-by: Csókás, Bence <csokas.bence@prolan.hu>
    Reviewed-by: Alexander Dahl <ada@thorsis.com>
    Link: https://patch.msgid.link/20241122141302.2599636-1-csokas.bence@prolan.hu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b8520754f6d9b3a079cda6b2356f2acf616cba3
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Fri Nov 22 21:50:31 2024 +0530

    octeontx2-af: RPM: Fix mismatch in lmac type
    
    [ Upstream commit 7ebbbb23ea5b6d051509cb11399afac5042c9266 ]
    
    Due to a bug in the previous patch, there is a mismatch
    between the lmac type reported by the driver and the actual
    hardware configuration.
    
    Fixes: 3ad3f8f93c81 ("octeontx2-af: cn10k: MAC internal loopback support")
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86fd76e6e8808552ddaa5c90b163f20e8d190cd1
Author: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date:   Fri Nov 22 15:12:55 2024 +0100

    net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken
    
    [ Upstream commit 407618d66dba55e7db1278872e8be106808bbe91 ]
    
    On DWMAC3 and later, there's a RX Watchdog interrupt that's used for
    interrupt coalescing. It's known to be buggy on some platforms, and
    dwmac-socfpga appears to be one of them. Changing the interrupt
    coalescing from ethtool doesn't appear to have any effect here.
    
    Without disabling RIWT (Received Interrupt Watchdog Timer, I
    believe...), we observe latencies while receiving traffic that amount to
    around ~0.4ms. This was discovered with NTP but can be easily reproduced
    with a simple ping. Without this patch :
    
    64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.657 ms
    
    With this patch :
    
    64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.254 ms
    
    Fixes: 801d233b7302 ("net: stmmac: Add SOCFPGA glue driver")
    Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Link: https://patch.msgid.link/20241122141256.764578-1-maxime.chevallier@bootlin.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c93792cad8c87f43a204257216c181ddcf2aded1
Author: Vitalii Mordan <mordan@ispras.ru>
Date:   Thu Nov 21 23:06:58 2024 +0300

    marvell: pxa168_eth: fix call balance of pep->clk handling routines
    
    [ Upstream commit b032ae57d4fe2b2445e3bc190db6fcaa8c102f68 ]
    
    If the clock pep->clk was not enabled in pxa168_eth_probe,
    it should not be disabled in any path.
    
    Conversely, if it was enabled in pxa168_eth_probe, it must be disabled
    in all error paths to ensure proper cleanup.
    
    Use the devm_clk_get_enabled helper function to ensure proper call balance
    for pep->clk.
    
    Found by Linux Verification Center (linuxtesting.org) with Klever.
    
    Fixes: a49f37eed22b ("net: add Fast Ethernet driver for PXA168.")
    Signed-off-by: Vitalii Mordan <mordan@ispras.ru>
    Link: https://patch.msgid.link/20241121200658.2203871-1-mordan@ispras.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a2c2ca00e65c7c51d20ab12e424d1c6544d0678
Author: Rosen Penev <rosenp@gmail.com>
Date:   Thu Nov 21 11:31:52 2024 -0800

    net: mdio-ipq4019: add missing error check
    
    [ Upstream commit 9cc8d0ecdd2aad42e377e971e3bb114339df609e ]
    
    If an optional resource is found but fails to remap, return on failure.
    Avoids any potential problems when using the iomapped resource as the
    assumption is that it's available.
    
    Fixes: 23a890d493e3 ("net: mdio: Add the reset function for IPQ MDIO driver")
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20241121193152.8966-1-rosenp@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca97dd10424860a3806ad3a9e26b9dce2901ee0c
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Nov 20 09:51:07 2024 +0000

    net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged
    
    [ Upstream commit 00b5b7aab9e422d00d5a9d03d7e0760a76b5d57f ]
    
    RFC8981 section 3.4 says that existing temporary addresses must have their
    lifetimes adjusted so that no temporary addresses should ever remain "valid"
    or "preferred" longer than the incoming SLAAC Prefix Information. This would
    strongly imply in Linux's case that if the "mngtmpaddr" address is deleted or
    un-flagged as such, its corresponding temporary addresses must be cleared out
    right away.
    
    But now the temporary address is renewed even after ‘mngtmpaddr’ is removed
    or becomes unmanaged as manage_tempaddrs() set temporary addresses
    prefered/valid time to 0, and later in addrconf_verify_rtnl() all checkings
    failed to remove the addresses. Fix this by deleting the temporary address
    directly for these situations.
    
    Fixes: 778964f2fdf0 ("ipv6/addrconf: fix timing bug in tempaddr regen")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 934326aef7ac4652f81c69d18bf44eebaefc39c3
Author: Sidraya Jayagond <sidraya@linux.ibm.com>
Date:   Tue Nov 19 16:22:19 2024 +0100

    s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
    
    [ Upstream commit ebaf81317e42aa990ad20b113cfe3a7b20d4e937 ]
    
    Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount
    (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount
    at exit.
    This results in skb memory leak in skb_queue_purge() and WARN_ON in
    iucv_sock_destruct() during socket close. To fix this decrease
    skb refcount by one if MSG_PEEK is set in order to prevent memory
    leak and WARN_ON.
    
    WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]
    CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G        W          6.10.0-rc7 #1
    Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
    Call Trace:
            [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv]
            [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv]
            [<001587c704117a32>] __sk_destruct+0x52/0x550
            [<001587c704104a54>] __sock_release+0xa4/0x230
            [<001587c704104c0c>] sock_close+0x2c/0x40
            [<001587c702c5f5a8>] __fput+0x2e8/0x970
            [<001587c7024148c4>] task_work_run+0x1c4/0x2c0
            [<001587c7023b0716>] do_exit+0x996/0x1050
            [<001587c7023b13aa>] do_group_exit+0x13a/0x360
            [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60
            [<001587c7022bccca>] do_syscall+0x27a/0x380
            [<001587c7049a6a0c>] __do_syscall+0x9c/0x160
            [<001587c7049ce8a8>] system_call+0x70/0x98
            Last Breaking-Event-Address:
            [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]
    
    Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support")
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: Thorsten Winkler <twinkler@linux.ibm.com>
    Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: David Wei <dw@davidwei.uk>
    Link: https://patch.msgid.link/20241119152219.3712168-1-wintera@linux.ibm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd11087343ec43c9b1cd18bb788a24f02b082bb5
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Mon Nov 18 15:03:51 2024 +0100

    net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL configuration
    
    [ Upstream commit e863ff806f72098bccaf8fa89c80d9ad6187c3b0 ]
    
    Validate Wake-on-LAN (WoL) options in `lan78xx_set_wol` before calling
    `usb_autopm_get_interface`. This prevents USB autopm refcounting issues
    and ensures the adapter can properly enter autosuspend when invalid WoL
    options are provided.
    
    Fixes: eb9ad088f966 ("lan78xx: Check for supported Wake-on-LAN modes")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://patch.msgid.link/20241118140351.2398166-1-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef71bab156fa387f748522740950db4ce21d3ff7
Author: Pavan Chebbi <pavan.chebbi@broadcom.com>
Date:   Mon Nov 18 21:57:41 2024 -0800

    tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets
    
    [ Upstream commit 614f4d166eeeb9bd709b0ad29552f691c0f45776 ]
    
    The hardware on Broadcom 1G chipsets have a known limitation
    where they cannot handle DMA addresses that cross over 4GB.
    When such an address is encountered, the hardware sets the
    address overflow error bit in the DMA status register and
    triggers a reset.
    
    However, BCM57766 hardware is setting the overflow bit and
    triggering a reset in some cases when there is no actual
    underlying address overflow. The hardware team analyzed the
    issue and concluded that it is happening when the status
    block update has an address with higher (b16 to b31) bits
    as 0xffff following a previous update that had lowest bits
    as 0xffff.
    
    To work around this bug in the BCM57766 hardware, set the
    coherent dma mask from the current 64b to 31b. This will
    ensure that upper bits of the status block DMA address are
    always at most 0x7fff, thus avoiding the improper overflow
    check described above. This work around is intended for only
    status block and ring memories and has no effect on TX and
    RX buffers as they do not require coherent memory.
    
    Fixes: 72f2afb8a685 ("[TG3]: Add DMA address workaround")
    Reported-by: Salam Noureddine <noureddine@arista.com>
    Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Link: https://patch.msgid.link/20241119055741.147144-1-pavan.chebbi@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a217fc39588a2378965e019d77b840d4cf02f4f8
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Sat Nov 16 14:05:58 2024 +0100

    net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device
    
    [ Upstream commit ae7370e61c5d8f5bcefc2d4fca724bd4e9bbf789 ]
    
    Add calls to `phy_device_free` after `fixed_phy_unregister` to fix a
    memory leak that occurs when the device is unplugged. This ensures
    proper cleanup of pseudo fixed-link PHYs.
    
    Fixes: 89b36fb5e532 ("lan78xx: Lan7801 Support for Fixed PHY")
    Cc: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://patch.msgid.link/20241116130558.1352230-2-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 977128343fc2a30737399b58df8ea77e94f164bd
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Sat Nov 16 14:05:57 2024 +0100

    net: usb: lan78xx: Fix double free issue with interrupt buffer allocation
    
    [ Upstream commit 03819abbeb11117dcbba40bfe322b88c0c88a6b6 ]
    
    In lan78xx_probe(), the buffer `buf` was being freed twice: once
    implicitly through `usb_free_urb(dev->urb_intr)` with the
    `URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused
    a double free issue.
    
    To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to
    simplify the initialization sequence and removed the redundant
    `kfree(buf)`.  Now, `buf` is allocated after `usb_alloc_urb()`, ensuring
    it is correctly managed by  `usb_fill_int_urb()` and freed by
    `usb_free_urb()` as intended.
    
    Fixes: a6df95cae40b ("lan78xx: Fix memory allocation bug")
    Cc: John Efstathiades <john.efstathiades@pebblebay.com>
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://patch.msgid.link/20241116130558.1352230-1-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42bc30da3489b0ba25ccab1035b5f10e5690953f
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>
Date:   Wed Oct 16 20:54:05 2024 +0200

    power: supply: bq27xxx: Fix registers of bq27426
    
    [ Upstream commit 34f99d3b706a519e556841f405c224ca708b1f54 ]
    
    Correct bq27426 registers, according to technical reference manual
    it does not have Design Capacity register so it is not register
    compatible with bq27421.
    
    Fixes: 5ef6a16033b47 ("power: supply: bq27xxx: Add support for BQ27426")
    Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
    Link: https://lore.kernel.org/r/20241016-fix_bq27426-v2-1-aa6c0f51a9f6@mainlining.org
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc7c33eec3f07d753de7ce952268550350f5640c
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Sep 17 12:39:14 2024 -0700

    power: supply: core: Remove might_sleep() from power_supply_put()
    
    [ Upstream commit f6da4553ff24a5d1c959c9627c965323adc3d307 ]
    
    The put_device() call in power_supply_put() may call
    power_supply_dev_release(). The latter function does not sleep so
    power_supply_put() doesn't sleep either. Hence, remove the might_sleep()
    call from power_supply_put(). This patch suppresses false positive
    complaints about calling a sleeping function from atomic context if
    power_supply_put() is called from atomic context.
    
    Cc: Kyle Tso <kyletso@google.com>
    Cc: Krzysztof Kozlowski <krzk@kernel.org>
    Fixes: 1a352462b537 ("power_supply: Add power_supply_put for decrementing device reference counter")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240917193914.47566-1-bvanassche@acm.org
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8382e92f90b601acf6d426121e6f4991502e767d
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Fri Nov 22 15:47:48 2024 +0800

    LoongArch: BPF: Sign-extend return values
    
    [ Upstream commit 73c359d1d356cf10236ccd358bd55edab33e9424 ]
    
    (1) Description of Problem:
    
    When testing BPF JIT with the latest compiler toolchains on LoongArch,
    there exist some strange failed test cases, dmesg shows something like
    this:
    
      # dmesg -t | grep FAIL | head -1
      ... ret -3 != -3 (0xfffffffd != 0xfffffffd)FAIL ...
    
    (2) Steps to Reproduce:
    
      # echo 1 > /proc/sys/net/core/bpf_jit_enable
      # modprobe test_bpf
    
    (3) Additional Info:
    
    There are no failed test cases compiled with the lower version of GCC
    such as 13.3.0, while the problems only appear with higher version of
    GCC such as 14.2.0.
    
    This is because the problems were hidden by the lower version of GCC due
    to redundant sign extension instructions generated by compiler, but with
    optimization of higher version of GCC, the sign extension instructions
    have been removed.
    
    (4) Root Cause Analysis:
    
    The LoongArch architecture does not expose sub-registers, and hold all
    32-bit values in a sign-extended format. While BPF, on the other hand,
    exposes sub-registers, and use zero-extension (similar to arm64/x86).
    
    This has led to some subtle bugs, where a BPF JITted program has not
    sign-extended the a0 register (return value in LoongArch land), passed
    the return value up the kernel, for example:
    
      | int from_bpf(void);
      |
      | long foo(void)
      | {
      |    return from_bpf();
      | }
    
    Here, a0 would be 0xffffffff instead of the expected 0xffffffffffffffff.
    
    Internally, the LoongArch JIT uses a5 as a dedicated register for BPF
    return values. That is to say, the LoongArch BPF uses a5 for BPF return
    values, which are zero-extended, whereas the LoongArch ABI uses a0 which
    is sign-extended.
    
    (5) Final Solution:
    
    Keep a5 zero-extended, but explicitly sign-extend a0 (which is used
    outside BPF land). Because libbpf currently defines the return value
    of an ebpf program as a 32-bit unsigned integer, just use addi.w to
    extend bit 31 into bits 63 through 32 of a5 to a0. This is similar to
    commit 2f1b0d3d7331 ("riscv, bpf: Sign-extend return values").
    
    Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcfb04e974b25e0a243fb273a78ab31cd4f86ed0
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Fri Nov 22 15:47:47 2024 +0800

    LoongArch: Fix build failure with GCC 15 (-std=gnu23)
    
    [ Upstream commit 947d5d036c788156f09e83e7f16322ffe8124384 ]
    
    Whenever I try to build the kernel with upcoming GCC 15 which defaults
    to -std=gnu23 I get a build failure:
    
      CC      arch/loongarch/vdso/vgetcpu.o
    In file included from ./include/uapi/linux/posix_types.h:5,
                     from ./include/uapi/linux/types.h:14,
                     from ./include/linux/types.h:6,
                     from ./include/linux/kasan-checks.h:5,
                     from ./include/asm-generic/rwonce.h:26,
                     from ./arch/loongarch/include/generated/asm/rwonce.h:1,
                     from ./include/linux/compiler.h:317,
                     from ./include/asm-generic/bug.h:5,
                     from ./arch/loongarch/include/asm/bug.h:60,
                     from ./include/linux/bug.h:5,
                     from ./include/linux/mmdebug.h:5,
                     from ./include/linux/mm.h:6,
                     from ./arch/loongarch/include/asm/vdso.h:10,
                     from arch/loongarch/vdso/vgetcpu.c:6:
    ./include/linux/stddef.h:11:9: error: expected identifier before 'false'
       11 |         false   = 0,
          |         ^~~~~
    ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
       35 | typedef _Bool                   bool;
          |                                 ^~~~
    ./include/linux/types.h:35:1: warning: useless type name in empty declaration
       35 | typedef _Bool                   bool;
          | ^~~~~~~
    
    The kernel builds explicitly with -std=gnu11 in top Makefile, but
    arch/loongarch/vdso does not use KBUILD_CFLAGS from the rest of the
    kernel, just add -std=gnu11 flag to arch/loongarch/vdso/Makefile.
    
    By the way, commit e8c07082a810 ("Kbuild: move to -std=gnu11") did a
    similar change for arch/arm64/kernel/vdso32/Makefile.
    
    Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support")
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9db9e4d50b8998e566c6374547ad4508bc2b20b8
Author: WANG Xuerui <git@xen0n.name>
Date:   Thu Jun 29 20:58:43 2023 +0800

    LoongArch: Tweak CFLAGS for Clang compatibility
    
    [ Upstream commit 38b10b269d04540aee05c34a059dcf304cfce0a8 ]
    
    Now the arch code is mostly ready for LLVM/Clang consumption, it is time
    to re-organize the CFLAGS a little to actually enable the LLVM build.
    Namely, all -G0 switches from CFLAGS are removed, and -mexplicit-relocs
    and -mdirect-extern-access are now wrapped with cc-option (with the
    related asm/percpu.h definition guarded against toolchain combos that
    are known to not work).
    
    A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU
    environment; support for the two features are currently blocked on
    LLVM/Clang, and will come later.
    
    Why -G0 can be removed:
    
    In GCC, -G stands for "small data threshold", that instructs the
    compiler to put data smaller than the specified threshold in a dedicated
    "small data" section (called .sdata on LoongArch and several other
    arches).
    
    However, benefiting from this would require ABI cooperation, which is
    not the case for LoongArch; and current GCC behave the same whether -G0
    (equal to disabling this optimization) is given or not. So, remove -G0
    from CFLAGS altogether for one less thing to care about. This also
    benefits LLVM/Clang compatibility where the -G switch is not supported.
    
    Why -mexplicit-relocs can now be conditionally applied without
    regressions:
    
    Originally -mexplicit-relocs is unconditionally added to CFLAGS in case
    of CONFIG_AS_HAS_EXPLICIT_RELOCS, because not having it (i.e. old GCC +
    new binutils) would not work: modules will have R_LARCH_ABS_* relocs
    inside, but given the rarity of such toolchain combo in the wild, it may
    not be worthwhile to support it, so support for such relocs in modules
    were not added back when explicit relocs support was upstreamed, and
    -mexplicit-relocs is unconditionally added to fail the build early.
    
    Now that Clang compatibility is desired, given Clang is behaving like
    -mexplicit-relocs from day one but without support for the CLI flag, we
    must ensure the flag is not passed in case of Clang. However, explicit
    compiler flavor checks can be more brittle than feature detection: in
    this case what actually matters is support for __attribute__((model))
    when building modules. Given neither older GCC nor current Clang support
    this attribute, probing for the attribute support and #error'ing out
    would allow proper UX without checking for Clang, and also automatically
    work when Clang support for the attribute is to be added in the future.
    
    Why -mdirect-extern-access is now conditionally applied:
    
    This is actually a nice-to-have optimization that can reduce GOT
    accesses, but not having it is harmless either. Because Clang does not
    support the option currently, but might do so in the future, conditional
    application via cc-option ensures compatibility with both current and
    future Clang versions.
    
    Suggested-by: Xi Ruoyao <xry111@xry111.site> # cc-option changes
    Signed-off-by: WANG Xuerui <git@xen0n.name>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Stable-dep-of: 947d5d036c78 ("LoongArch: Fix build failure with GCC 15 (-std=gnu23)")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df10201960934e39f133a9cbaf1f1dcd9f668ead
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Nov 25 13:50:21 2024 -0800

    fs_parser: update mount_api doc to match function signature
    
    [ Upstream commit c66f759832a83cb273ba5a55c66dcc99384efa74 ]
    
    Add the missing 'name' parameter to the mount_api documentation for
    fs_validate_description().
    
    Fixes: 96cafb9ccb15 ("fs_parser: remove fs_parameter_description name field")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20241125215021.231758-1-rdunlap@infradead.org
    Cc: Eric Sandeen <sandeen@redhat.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: linux-doc@vger.kernel.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c6502d944168cbd7e03a4a08ad6488f78d73485
Author: Avihai Horon <avihaih@nvidia.com>
Date:   Sun Nov 24 16:27:39 2024 +0200

    vfio/pci: Properly hide first-in-list PCIe extended capability
    
    [ Upstream commit fe4bf8d0b6716a423b16495d55b35d3fe515905d ]
    
    There are cases where a PCIe extended capability should be hidden from
    the user. For example, an unknown capability (i.e., capability with ID
    greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally
    chosen to be hidden from the user.
    
    Hiding a capability is done by virtualizing and modifying the 'Next
    Capability Offset' field of the previous capability so it points to the
    capability after the one that should be hidden.
    
    The special case where the first capability in the list should be hidden
    is handled differently because there is no previous capability that can
    be modified. In this case, the capability ID and version are zeroed
    while leaving the next pointer intact. This hides the capability and
    leaves an anchor for the rest of the capability list.
    
    However, today, hiding the first capability in the list is not done
    properly if the capability is unknown, as struct
    vfio_pci_core_device->pci_config_map is set to the capability ID during
    initialization but the capability ID is not properly checked later when
    used in vfio_config_do_rw(). This leads to the following warning [1] and
    to an out-of-bounds access to ecap_perms array.
    
    Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater
    than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct
    read only access instead of the ecap_perms array.
    
    Note that this is safe since the above is the only case where cap_id can
    exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which
    are already checked before).
    
    [1]
    
    WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
    CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1
    (snip)
    Call Trace:
     <TASK>
     ? show_regs+0x69/0x80
     ? __warn+0x8d/0x140
     ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
     ? report_bug+0x18f/0x1a0
     ? handle_bug+0x63/0xa0
     ? exc_invalid_op+0x19/0x70
     ? asm_exc_invalid_op+0x1b/0x20
     ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
     ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]
     vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]
     vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]
     vfio_device_fops_read+0x27/0x40 [vfio]
     vfs_read+0xbd/0x340
     ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]
     ? __rseq_handle_notify_resume+0xa4/0x4b0
     __x64_sys_pread64+0x96/0xc0
     x64_sys_call+0x1c3d/0x20d0
     do_syscall_64+0x4d/0x120
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Signed-off-by: Avihai Horon <avihaih@nvidia.com>
    Reviewed-by: Yi Liu <yi.l.liu@intel.com>
    Tested-by: Yi Liu <yi.l.liu@intel.com>
    Link: https://lore.kernel.org/r/20241124142739.21698-1-avihaih@nvidia.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea3f18a680ec7e4a0391bc3a8a4252a4eb8828f8
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Sat Nov 16 00:41:14 2024 +1100

    selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels
    
    [ Upstream commit f13242a46438e690067a4bf47068fde4d5719947 ]
    
    Currently the mount_setattr_test fails on machines with a 64K PAGE_SIZE,
    with errors such as:
    
      #  RUN           mount_setattr_idmapped.invalid_fd_negative ...
      mkfs.ext4: No space left on device while writing out and closing file system
      # mount_setattr_test.c:1055:invalid_fd_negative:Expected system("mkfs.ext4 -q /mnt/C/ext4.img") (256) == 0 (0)
      # invalid_fd_negative: Test terminated by assertion
      #          FAIL  mount_setattr_idmapped.invalid_fd_negative
      not ok 12 mount_setattr_idmapped.invalid_fd_negative
    
    The code creates a 100,000 byte tmpfs:
    
            ASSERT_EQ(mount("testing", "/mnt", "tmpfs", MS_NOATIME | MS_NODEV,
                            "size=100000,mode=700"), 0);
    
    And then a little later creates a 2MB ext4 filesystem in that tmpfs:
    
            ASSERT_EQ(ftruncate(img_fd, 1024 * 2048), 0);
            ASSERT_EQ(system("mkfs.ext4 -q /mnt/C/ext4.img"), 0);
    
    At first glance it seems like that should never work, after all 2MB is
    larger than 100,000 bytes. However the filesystem image doesn't actually
    occupy 2MB on "disk" (actually RAM, due to tmpfs). On 4K kernels the
    ext4.img uses ~84KB of actual space (according to du), which just fits.
    
    However on 64K PAGE_SIZE kernels the ext4.img takes at least 256KB,
    which is too large to fit in the tmpfs, hence the errors.
    
    It seems fraught to rely on the ext4.img taking less space on disk than
    the allocated size, so instead create the tmpfs with a size of 2MB. With
    that all 21 tests pass on 64K PAGE_SIZE kernels.
    
    Fixes: 01eadc8dd96d ("tests: add mount_setattr() selftests")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20241115134114.1219555-1-mpe@ellerman.id.au
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c8938844ed76efc5d6f5edbfa0f10e777a38fc8
Author: Si-Wei Liu <si-wei.liu@oracle.com>
Date:   Mon Oct 21 16:40:40 2024 +0300

    vdpa/mlx5: Fix suboptimal range on iotlb iteration
    
    [ Upstream commit 35025963326e44d8bced3eecd42d2f040f4f0024 ]
    
    The starting iova address to iterate iotlb map entry within a range
    was set to an irrelevant value when passing to the itree_next()
    iterator, although luckily it doesn't affect the outcome of finding
    out the granule of the smallest iotlb map size. Fix the code to make
    it consistent with the following for-loop.
    
    Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
    Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
    Message-Id: <20241021134040.975221-3-dtatulea@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc4f7dde470cdacad0de1eef60b52b98e10c9487
Author: Murad Masimov <m.masimov@maxima.ru>
Date:   Thu Nov 21 20:36:03 2024 +0300

    hwmon: (tps23861) Fix reporting of negative temperatures
    
    [ Upstream commit de2bf507fabba9c0c678cf5ed54beb546f5ca29a ]
    
    Negative temperatures are reported as large positive temperatures
    due to missing sign extension from unsigned int to long. Cast unsigned
    raw register values to signed before performing the calculations
    to fix the problem.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: fff7b8ab2255 ("hwmon: add Texas Instruments TPS23861 driver")
    Signed-off-by: Murad Masimov <m.masimov@maxima.ru>
    Message-ID: <20241121173604.2021-1-m.masimov@maxima.ru>
    [groeck: Updated subject and description]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ee368b4471bd2963d6d23ea5542e70f160da666
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Oct 31 09:40:03 2024 -0400

    NFSD: Fix nfsd4_shutdown_copy()
    
    [ Upstream commit 62a8642ba00aa8ceb0a02ade942f5ec52e877c95 ]
    
    nfsd4_shutdown_copy() is just this:
    
            while ((copy = nfsd4_get_copy(clp)) != NULL)
                    nfsd4_stop_copy(copy);
    
    nfsd4_get_copy() bumps @copy's reference count, preventing
    nfsd4_stop_copy() from releasing @copy.
    
    A while loop like this usually works by removing the first element
    of the list, but neither nfsd4_get_copy() nor nfsd4_stop_copy()
    alters the async_copies list.
    
    Best I can tell, then, is that nfsd4_shutdown_copy() continues to
    loop until other threads manage to remove all the items from this
    list. The spinning loop blocks shutdown until these items are gone.
    
    Possibly the reason we haven't seen this issue in the field is
    because client_has_state() prevents __destroy_client() from calling
    nfsd4_shutdown_copy() if there are any items on this list. In a
    subsequent patch I plan to remove that restriction.
    
    Fixes: e0639dc5805a ("NFSD introduce async copy feature")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94d2d6d398706ab7218a26d61e12919c4b498e09
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Oct 24 09:55:20 2024 +0800

    svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()
    
    [ Upstream commit ce89e742a4c12b20f09a43fec1b21db33f2166cd ]
    
    There's issue as follows:
    RPC: Registered rdma transport module.
    RPC: Registered rdma backchannel transport module.
    RPC: Unregistered rdma transport module.
    RPC: Unregistered rdma backchannel transport module.
    BUG: unable to handle page fault for address: fffffbfff80c609a
    PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0
    Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
    RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0
    Call Trace:
     <TASK>
     __die+0x1f/0x70
     page_fault_oops+0x2cd/0x860
     spurious_kernel_fault+0x36/0x450
     do_kern_addr_fault+0xca/0x100
     exc_page_fault+0x128/0x150
     asm_exc_page_fault+0x26/0x30
     percpu_counter_destroy_many+0xf7/0x2a0
     mmdrop+0x209/0x350
     finish_task_switch.isra.0+0x481/0x840
     schedule_tail+0xe/0xd0
     ret_from_fork+0x23/0x80
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not
    destroy the percpu counters which init in svc_rdma_proc_init().
    If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the
    'percpu_counters' list. The above issue may occur once the module is
    removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory
    leakage occurs.
    To solve above issue just destroy all percpu counters when
    register_sysctl() return NULL.
    
    Fixes: 1e7e55731628 ("svcrdma: Restore read and write stats")
    Fixes: 22df5a22462e ("svcrdma: Convert rdma_stat_sq_starve to a per-CPU counter")
    Fixes: df971cd853c0 ("svcrdma: Convert rdma_stat_recv to a per-CPU counter")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f143df272cc15187ab91b5c62c57b0da75099ab6
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Sat Mar 11 15:39:40 2023 -0800

    sunrpc: simplify two-level sysctl registration for svcrdma_parm_table
    
    [ Upstream commit 376bcd9b37632cf191711a68aa25ab42f0048c2e ]
    
    There is no need to declare two tables to just create directories,
    this can be easily be done with a prefix path with register_sysctl().
    
    Simplify this registration.
    
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Stable-dep-of: ce89e742a4c1 ("svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03b72929f72bfc620a12a1ba3c0f79a866e778f8
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Oct 17 11:03:56 2024 -0400

    NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()
    
    [ Upstream commit f64ea4af43161bb86ffc77e6aeb5bcf5c3229df0 ]
    
    It's only current caller already length-checks the string, but let's
    be safe.
    
    Fixes: 0964a3d3f1aa ("[PATCH] knfsd: nfsd4 reboot dirname fix")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c3b0e326f838787d229314d4de83af9c53347e8
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Oct 17 11:03:53 2024 -0400

    NFSD: Prevent NULL dereference in nfsd4_process_cb_update()
    
    [ Upstream commit 1e02c641c3a43c88cecc08402000418e15578d38 ]
    
    @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no
    available backchannel session, setup_callback_client() will try to
    dereference @ses and segfault.
    
    Fixes: dcbeaa68dbbd ("nfsd4: allow backchannel recovery")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1cc346cf7606b77ab86f43c8c83817de28c09cb
Author: Sibi Sankar <quic_sibis@quicinc.com>
Date:   Mon Aug 19 13:00:20 2024 +0530

    remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region
    
    [ Upstream commit 7b22b7719fc17d5979a991c918c868ab041be5c8 ]
    
    Any write access to the IMEM region when the Q6 is setting up XPU
    protection on it will result in a XPU violation. Fix this by ensuring
    IMEM writes related to the MBA post-mortem logs happen before the Q6
    is brought out of reset.
    
    Fixes: 318130cc9362 ("remoteproc: qcom_q6v5_mss: Add MBA log extraction support")
    Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20240819073020.3291287-1-quic_sibis@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a572eb5078b99c8eb7f5620b43e59393457433fe
Author: Jonathan Marek <jonathan@marek.ca>
Date:   Mon Oct 7 19:59:35 2024 -0400

    rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length
    
    [ Upstream commit 06c59d97f63c1b8af521fa5aef8a716fb988b285 ]
    
    The name len field of the CMD_OPEN packet is only 16-bits and the upper
    16-bits of "param2" are a different "prio" field, which can be nonzero in
    certain situations, and CMD_OPEN packets can be unexpectedly dropped
    because of this.
    
    Fix this by masking out the upper 16 bits of param2.
    
    Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
    Signed-off-by: Jonathan Marek <jonathan@marek.ca>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20241007235935.6216-1-jonathan@marek.ca
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ad64de59188e5bc7b1c160fa6ba93654238b199
Author: Bjorn Andersson <quic_bjorande@quicinc.com>
Date:   Tue Feb 14 14:59:33 2023 -0800

    rpmsg: glink: Fix GLINK command prefix
    
    [ Upstream commit 4e816d0318fdfe8932da80dbf04ba318b13e4b3a ]
    
    The upstream GLINK driver was first introduced to communicate with the
    RPM on MSM8996, presumably as an artifact from that era the command
    defines was prefixed RPM_CMD, while they actually are GLINK_CMDs.
    
    Let's rename these, to keep things tidy. No functional change.
    
    Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Reviewed-by: Chris Lew <quic_clew@quicinc.com>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20230214225933.2025595-1-quic_bjorande@quicinc.com
    Stable-dep-of: 06c59d97f63c ("rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79327e3662fc64134b45a548dcb4921439d8c398
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Oct 27 01:09:44 2024 +0300

    remoteproc: qcom: pas: add minidump_id to SM8350 resources
    
    [ Upstream commit e8983156d54f59f57e648ecd44f01c16572da842 ]
    
    Specify minidump_id for the SM8350 DSPs. It was omitted for in the
    original commit e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS
    remoteprocs").
    
    Fixes: e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20241027-sar2130p-adsp-v1-2-bd204e39d24e@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e115f31c355d1d6e71a7f6a3de602c306571179
Author: Abel Vesa <abel.vesa@linaro.org>
Date:   Mon Jul 18 15:15:14 2022 +0300

    remoteproc: qcom: q6v5: Use _clk_get_optional for aggre2_clk
    
    [ Upstream commit 6d967a5a49e8d08d8e4430aadba8d3c903b794a5 ]
    
    Only msm8996 and msm8998 SLPIs need the RPM_SMD_AGGR2_NOC_CLK
    (as aggre2 clock). None of the other platforms do. Back when the support
    for the mentioned platforms was added to the q6v5 pass driver, the
    devm_clk_get_optional was not available, so the has_aggre2_clk was
    necessary in order to differentiate between plaforms that need this
    clock and those which do not. Now that devm_clk_get_optional is available,
    we can drop the has_aggre2_clk. This makes the adsp_data more cleaner
    and removes the check within adsp_init_clocks.
    
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20220718121514.2451590-1-abel.vesa@linaro.org
    Stable-dep-of: e8983156d54f ("remoteproc: qcom: pas: add minidump_id to SM8350 resources")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57ef7705a3e485d9b14bfd6a3c1cd4e4b5a3dadf
Author: Benjamin Peterson <benjamin@engflow.com>
Date:   Thu Nov 7 23:21:27 2024 +0000

    perf trace: Avoid garbage when not printing a syscall's arguments
    
    [ Upstream commit 1302e352b26f34991b619b5d0b621b76d20a3883 ]
    
    syscall__scnprintf_args may not place anything in the output buffer
    (e.g., because the arguments are all zero). If that happened in
    trace__fprintf_sys_enter, its fprintf would receive an unitialized
    buffer leading to garbage output.
    
    Fix the problem by passing the (possibly zero) bounds of the argument
    buffer to the output fprintf.
    
    Fixes: a98392bb1e169a04 ("perf trace: Use beautifiers on syscalls:sys_enter_ handlers")
    Signed-off-by: Benjamin Peterson <benjamin@engflow.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Howard Chu <howardchu95@gmail.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241107232128.108981-2-benjamin@engflow.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b601e05c43b7226fe595018c0d22c86d7f1cd92
Author: Benjamin Peterson <benjamin@engflow.com>
Date:   Thu Nov 7 23:21:26 2024 +0000

    perf trace: Do not lose last events in a race
    
    [ Upstream commit 3fd7c36973a250e17a4ee305a31545a9426021f4 ]
    
    If a perf trace event selector specifies a maximum number of events to output
    (i.e., "/nr=N/" syntax), the event printing handler, trace__event_handler,
    disables the event selector after the maximum number events are
    printed.
    
    Furthermore, trace__event_handler checked if the event selector was
    disabled before doing any work. This avoided exceeding the maximum
    number of events to print if more events were in the buffer before the
    selector was disabled.
    
    However, the event selector can be disabled for reasons other than
    exceeding the maximum number of events. In particular, when the traced
    subprocess exits, the main loop disables all event selectors. This meant
    the last events of a traced subprocess might be lost to the printing
    handler's short-circuiting logic.
    
    This nondeterministic problem could be seen by running the following many times:
    
      $ perf trace -e syscalls:sys_enter_exit_group true
    
    trace__event_handler should simply check for exceeding the maximum number of
    events to print rather than the state of the event selector.
    
    Fixes: a9c5e6c1e9bff42c ("perf trace: Introduce per-event maximum number of events property")
    Signed-off-by: Benjamin Peterson <benjamin@engflow.com>
    Tested-by: Howard Chu <howardchu95@gmail.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241107232128.108981-1-benjamin@engflow.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1f8195bf68edd2cef0f18a4cead394075a54b5a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Sep 17 12:15:29 2024 -0400

    svcrdma: Address an integer overflow
    
    [ Upstream commit 3c63d8946e578663b868cb9912dac616ea68bfd0 ]
    
    Dan Carpenter reports:
    > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data
    > structure") from Jun 22, 2020 (linux-next), leads to the following
    > Smatch static checker warning:
    >
    >       net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()
    >       warn: potential user controlled sizeof overflow 'segcount * 4 * 4'
    >
    > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
    >     488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)
    >     489 {
    >     490         u32 segcount;
    >     491         __be32 *p;
    >     492
    >     493         if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))
    >                                                               ^^^^^^^^
    >
    >     494                 return false;
    >     495
    >     496         /* A bogus segcount causes this buffer overflow check to fail. */
    >     497         p = xdr_inline_decode(&rctxt->rc_stream,
    > --> 498                               segcount * rpcrdma_segment_maxsz * sizeof(*p));
    >
    >
    > segcount is an untrusted u32.  On 32bit systems anything >= SIZE_MAX / 16 will
    > have an integer overflow and some those values will be accepted by
    > xdr_inline_decode().
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Fixes: 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data structure")
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bab3e342768e64d2472b6d53537e6d6f1a189690
Author: Antonio Quartulli <antonio@mandelbit.com>
Date:   Tue Oct 29 22:43:15 2024 +0100

    m68k: coldfire/device.c: only build FEC when HW macros are defined
    
    [ Upstream commit 63a24cf8cc330e5a68ebd2e20ae200096974c475 ]
    
    When CONFIG_FEC is set (due to COMPILE_TEST) along with
    CONFIG_M54xx, coldfire/device.c has compile errors due to
    missing MCFEC_* and MCF_IRQ_FEC_* symbols.
    
    Make the whole FEC blocks dependent on having the HW macros
    defined, rather than on CONFIG_FEC itself.
    
    This fix is very similar to commit e6e1e7b19fa1 ("m68k: coldfire/device.c: only build for MCF_EDMA when h/w macros are defined")
    
    Fixes: b7ce7f0d0efc ("m68knommu: merge common ColdFire FEC platform setup code")
    To: Greg Ungerer <gerg@linux-m68k.org>
    To: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: linux-m68k@lists.linux-m68k.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
    Signed-off-by: Greg Ungerer <gerg@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3154c4320dbc777a50d7a2dcbbd6245fd5e88eb
Author: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
Date:   Wed Oct 16 09:24:35 2024 +0200

    m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x
    
    [ Upstream commit f212140962c93cd5da43283a18e31681540fc23d ]
    
    Fix a typo in the CONFIG_M5441x preprocessor condition, where the GPIO
    register offset was incorrectly set to 8 instead of 0. This prevented
    proper GPIO configuration for m5441x targets.
    
    Fixes: bea8bcb12da0 ("m68knommu: Add support for the Coldfire m5441x.")
    Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
    Signed-off-by: Greg Ungerer <gerg@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ac0ea38a85b61d11ebb0f55579205ff85aeacc7
Author: Benjamin Peterson <benjamin@engflow.com>
Date:   Sun Nov 3 20:48:16 2024 +0000

    perf trace: avoid garbage when not printing a trace event's arguments
    
    [ Upstream commit 5fb8e56542a3cf469fdf25d77f50e21cbff3ae7e ]
    
    trace__fprintf_tp_fields may not print any tracepoint arguments. E.g., if the
    argument values are all zero. Previously, this would result in a totally
    uninitialized buffer being passed to fprintf, which could lead to garbage on the
    console. Fix the problem by passing the number of initialized bytes fprintf.
    
    Fixes: f11b2803bb88 ("perf trace: Allow choosing how to augment the tracepoint arguments")
    Signed-off-by: Benjamin Peterson <benjamin@engflow.com>
    Tested-by: Howard Chu <howardchu95@gmail.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Link: https://lore.kernel.org/r/20241103204816.7834-1-benjamin@engflow.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e92bca0277f39d498de02d1fac92a94a7c8cc711
Author: Chao Yu <chao@kernel.org>
Date:   Mon Nov 4 09:50:16 2024 +0800

    f2fs: fix to avoid forcing direct write to use buffered IO on inline_data inode
    
    [ Upstream commit 26e6f59d0bbaac76fa3413462d780bd2b5f9f653 ]
    
    Jinsu Lee reported a performance regression issue, after commit
    5c8764f8679e ("f2fs: fix to force buffered IO on inline_data
    inode"), we forced direct write to use buffered IO on inline_data
    inode, it will cause performace regression due to memory copy
    and data flush.
    
    It's fine to not force direct write to use buffered IO, as it
    can convert inline inode before committing direct write IO.
    
    Fixes: 5c8764f8679e ("f2fs: fix to force buffered IO on inline_data inode")
    Reported-by: Jinsu Lee <jinsu1.lee@samsung.com>
    Closes: https://lore.kernel.org/linux-f2fs-devel/af03dd2c-e361-4f80-b2fd-39440766cf6e@kernel.org
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07c0787286daa955f6c6f2c7fb7668f7d4f208b8
Author: Zhiguo Niu <zhiguo.niu@unisoc.com>
Date:   Tue Oct 29 11:12:49 2024 +0800

    f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or GC_URGENT_MID
    
    [ Upstream commit 296b8cb34e65fa93382cf919be5a056f719c9a26 ]
    
    If gc_mode is set to GC_URGENT_LOW or GC_URGENT_MID, cost benefit GC
    approach should be used, but if ATGC is enabled at the same time,
    Age-threshold approach will be selected, which can only do amount of
    GC and it is much less than the numbers of CB approach.
    
    some traces:
      f2fs_gc-254:48-396     [007] ..... 2311600.684028: f2fs_gc_begin: dev = (254,48), gc_type = Background GC, no_background_GC = 0, nr_free_secs = 0, nodes = 1053, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0
      f2fs_gc-254:48-396     [007] ..... 2311600.684527: f2fs_get_victim: dev = (254,48), type = No TYPE, policy = (Background GC, LFS-mode, Age-threshold), victim = 10, cost = 4294364975, ofs_unit = 1, pre_victim_secno = -1, prefree = 0, free = 44898
      f2fs_gc-254:48-396     [007] ..... 2311600.714835: f2fs_gc_end: dev = (254,48), ret = 0, seg_freed = 0, sec_freed = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0
      f2fs_gc-254:48-396     [007] ..... 2311600.714843: f2fs_background_gc: dev = (254,48), wait_ms = 50, prefree = 0, free = 44898
      f2fs_gc-254:48-396     [007] ..... 2311600.771785: f2fs_gc_begin: dev = (254,48), gc_type = Background GC, no_background_GC = 0, nr_free_secs = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:
      f2fs_gc-254:48-396     [007] ..... 2311600.772275: f2fs_gc_end: dev = (254,48), ret = -61, seg_freed = 0, sec_freed = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0
    
    Fixes: 0e5e81114de1 ("f2fs: add GC_URGENT_LOW mode in gc_urgent")
    Fixes: d98af5f45520 ("f2fs: introduce gc_urgent_mid mode")
    Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4751fc0db8cef8c139a85416f3858433fb1e779
Author: Yongpeng Yang <yangyongpeng1@oppo.com>
Date:   Mon Oct 21 12:48:01 2024 +0800

    f2fs: check curseg->inited before write_sum_page in change_curseg
    
    [ Upstream commit 43563069e1c1df417d2eed6eca8a22fc6b04691d ]
    
    In the __f2fs_init_atgc_curseg->get_atssr_segment calling,
    curseg->segno is NULL_SEGNO, indicating that there is no summary
    block that needs to be written.
    
    Fixes: 093749e296e2 ("f2fs: support age threshold based garbage collection")
    Signed-off-by: Yongpeng Yang <yangyongpeng1@oppo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d3926eec7d885cccc5939a27f992983236b80eb
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Nov 28 10:43:46 2022 +0100

    f2fs: remove the unused flush argument to change_curseg
    
    [ Upstream commit 5bcd655fffaec24e849bda1207446f5cc821713e ]
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 43563069e1c1 ("f2fs: check curseg->inited before write_sum_page in change_curseg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3ba45c1764ed779d83fe8bdabef8b22a237a429
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Nov 28 10:43:45 2022 +0100

    f2fs: open code allocate_segment_by_default
    
    [ Upstream commit 8442d94b8ac8d5d8300725a9ffa9def526b71170 ]
    
    allocate_segment_by_default has just two callers, which use very
    different code pathes inside it based on the force paramter.  Just
    open code the logic in the two callers using a new helper to decided
    if a new segment should be allocated.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 43563069e1c1 ("f2fs: check curseg->inited before write_sum_page in change_curseg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d9b8b6ca9ebabfb8f8c8ef0ead4001c6499a351
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Nov 28 10:43:44 2022 +0100

    f2fs: remove struct segment_allocation default_salloc_ops
    
    [ Upstream commit 1c8a8ec0a0e9a1176022a35c4daf04fe1594d270 ]
    
    There is only  single instance of these ops, so remove the indirection
    and call allocate_segment_by_default directly.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 43563069e1c1 ("f2fs: check curseg->inited before write_sum_page in change_curseg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77f047d81cc7409f3f51029427ff88464b0d8f5b
Author: LongPing Wei <weilongping@oppo.com>
Date:   Mon Oct 21 10:31:47 2024 +0800

    f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block
    
    [ Upstream commit c3af1f13476ec23fd99c98d060a89be28c1e8871 ]
    
    This f2fs_bug_on was introduced by commit 2c1905042c8c ("f2fs: check
    segment type in __f2fs_replace_block") when there were only 6 curseg types.
    After commit d0b9e42ab615 ("f2fs: introduce inmem curseg") was introduced,
    the condition should be changed to checking curseg->seg_type.
    
    Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg")
    Signed-off-by: LongPing Wei <weilongping@oppo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afc63bbc9c7cc9f8e758974d52615f2ae75f871b
Author: Arnaldo Carvalho de Melo <acme@kernel.org>
Date:   Tue Oct 29 16:29:02 2024 -0300

    perf ftrace latency: Fix unit on histogram first entry when using --use-nsec
    
    [ Upstream commit 064d569e20e82c065b1dec9d20c29c7087bb1a00 ]
    
    The use_nsec arg wasn't being taken into account when printing the first
    histogram entry, fix it:
    
      root@number:~# perf ftrace latency --use-nsec -T switch_mm_irqs_off -a sleep 2
      #   DURATION     |      COUNT | GRAPH                                          |
           0 - 1    us |          0 |                                                |
           1 - 2    ns |          0 |                                                |
           2 - 4    ns |          0 |                                                |
           4 - 8    ns |          0 |                                                |
           8 - 16   ns |          0 |                                                |
          16 - 32   ns |          0 |                                                |
          32 - 64   ns |        125 |                                                |
          64 - 128  ns |        335 |                                                |
         128 - 256  ns |       2155 | ####                                           |
         256 - 512  ns |       9996 | ###################                            |
         512 - 1024 ns |       4958 | #########                                      |
           1 - 2    us |       4636 | #########                                      |
           2 - 4    us |       1053 | ##                                             |
           4 - 8    us |         15 |                                                |
           8 - 16   us |          1 |                                                |
          16 - 32   us |          0 |                                                |
          32 - 64   us |          0 |                                                |
          64 - 128  us |          0 |                                                |
         128 - 256  us |          0 |                                                |
         256 - 512  us |          0 |                                                |
         512 - 1024 us |          0 |                                                |
           1 - ...  ms |          0 |                                                |
      root@number:~#
    
    After:
    
      root@number:~# perf ftrace latency --use-nsec -T switch_mm_irqs_off -a sleep 2
      #   DURATION     |      COUNT | GRAPH                                          |
           0 - 1    ns |          0 |                                                |
           1 - 2    ns |          0 |                                                |
           2 - 4    ns |          0 |                                                |
           4 - 8    ns |          0 |                                                |
           8 - 16   ns |          0 |                                                |
          16 - 32   ns |          0 |                                                |
          32 - 64   ns |         19 |                                                |
          64 - 128  ns |         94 |                                                |
         128 - 256  ns |       2191 | ####                                           |
         256 - 512  ns |       9719 | ####################                           |
         512 - 1024 ns |       5330 | ###########                                    |
           1 - 2    us |       4104 | ########                                       |
           2 - 4    us |        807 | #                                              |
           4 - 8    us |          9 |                                                |
           8 - 16   us |          0 |                                                |
          16 - 32   us |          0 |                                                |
          32 - 64   us |          0 |                                                |
          64 - 128  us |          0 |                                                |
         128 - 256  us |          0 |                                                |
         256 - 512  us |          0 |                                                |
         512 - 1024 us |          0 |                                                |
           1 - ...  ms |          0 |                                                |
      root@number:~#
    
    Fixes: 84005bb6148618cc ("perf ftrace latency: Add -n/--use-nsec option")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Gabriele Monaco <gmonaco@redhat.com>
    Link: https://lore.kernel.org/r/ZyE3frB-hMXHCnMO@x1
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e9d6942d1440e508513d313d681a812f52d8323
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Oct 22 12:11:37 2024 +0300

    PCI: cpqphp: Fix PCIBIOS_* return value confusion
    
    [ Upstream commit e2226dbc4a4919d9c8bd9293299b532090bdf020 ]
    
    Code in and related to PCI_RefinedAccessConfig() has three types of return
    type confusion:
    
     - PCI_RefinedAccessConfig() tests pci_bus_read_config_dword() return value
       against -1.
    
     - PCI_RefinedAccessConfig() returns both -1 and PCIBIOS_* return codes.
    
     - Callers of PCI_RefinedAccessConfig() only test for -1.
    
    Make PCI_RefinedAccessConfig() return PCIBIOS_* codes consistently and
    adapt callers accordingly.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://lore.kernel.org/r/20241022091140.3504-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60f5d361ae3462e845d285dc2ef35daab3392699
Author: weiyufeng <weiyufeng@kylinos.cn>
Date:   Tue Aug 6 14:50:50 2024 +0800

    PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
    
    [ Upstream commit 87d5403378cccc557af9e02a8a2c8587ad8b7e9a ]
    
    Use PCI_POSSIBLE_ERROR() to check the response we get when we read data
    from hardware.  This unifies PCI error response checking and makes error
    checks consistent and easier to find.
    
    Link: https://lore.kernel.org/r/20240806065050.28725-1-412574090@163.com
    Signed-off-by: weiyufeng <weiyufeng@kylinos.cn>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Stable-dep-of: e2226dbc4a49 ("PCI: cpqphp: Fix PCIBIOS_* return value confusion")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 928883efee56e3d49a675f39082729aa55a5a819
Author: Leo Yan <leo.yan@arm.com>
Date:   Sat Oct 12 15:14:32 2024 +0100

    perf probe: Correct demangled symbols in C++ program
    
    [ Upstream commit 314909f13cc12d47c468602c37dace512d225eeb ]
    
    An issue can be observed when probe C++ demangled symbol with steps:
    
      # nm test_cpp_mangle | grep print_data
        0000000000000c94 t _GLOBAL__sub_I__Z10print_datai
        0000000000000afc T _Z10print_datai
        0000000000000b38 T _Z10print_dataR5Point
    
      # perf probe -x /home/niayan01/test_cpp_mangle -F --demangle
        ...
        print_data(Point&)
        print_data(int)
        ...
    
      # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)"
        probe-definition(0): test=print_data(int)
        symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Open Debuginfo file: /home/niayan01/test_cpp_mangle
        Try to find probe point from debuginfo.
        Symbol print_data(int) address found : afc
        Matched function: print_data [2ccf]
        Probe point found: print_data+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/tracing//uprobe_events write=1
        Opening /sys/kernel/tracing//README write=0
        Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xb38
        ...
    
    When tried to probe symbol "print_data(int)", the log shows:
    
        Symbol print_data(int) address found : afc
    
    The found address is 0xafc - which is right with verifying the output
    result from nm. Afterwards when write event, the command uses offset
    0xb38 in the last log, which is a wrong address.
    
    The dwarf_diename() gets a common function name, in above case, it
    returns string "print_data". As a result, the tool parses the offset
    based on the common name. This leads to probe at the wrong symbol
    "print_data(Point&)".
    
    To fix the issue, use the die_get_linkage_name() function to retrieve
    the distinct linkage name - this is the mangled name for the C++ case.
    Based on this unique name, the tool can get a correct offset for
    probing. Based on DWARF doc, it is possible the linkage name is missed
    in the DIE, it rolls back to use dwarf_diename().
    
    After:
    
      # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)"
        probe-definition(0): test=print_data(int)
        symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Open Debuginfo file: /home/niayan01/test_cpp_mangle
        Try to find probe point from debuginfo.
        Symbol print_data(int) address found : afc
        Matched function: print_data [2d06]
        Probe point found: print_data+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/tracing//uprobe_events write=1
        Opening /sys/kernel/tracing//README write=0
        Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xafc
        Added new event:
          probe_test_cpp_mangle:test (on print_data(int) in /home/niayan01/test_cpp_mangle)
    
        You can now use it in all perf tools, such as:
    
                perf record -e probe_test_cpp_mangle:test -aR sleep 1
    
      # perf --debug verbose=3 probe -x test_cpp_mangle --add "test2=print_data(Point&)"
        probe-definition(0): test2=print_data(Point&)
        symbol:print_data(Point&) file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Open Debuginfo file: /home/niayan01/test_cpp_mangle
        Try to find probe point from debuginfo.
        Symbol print_data(Point&) address found : b38
        Matched function: print_data [2ccf]
        Probe point found: print_data+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/tracing//uprobe_events write=1
        Parsing probe_events: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0x0000000000000afc
        Group:probe_test_cpp_mangle Event:test probe:p
        Opening /sys/kernel/tracing//README write=0
        Writing event: p:probe_test_cpp_mangle/test2 /home/niayan01/test_cpp_mangle:0xb38
        Added new event:
          probe_test_cpp_mangle:test2 (on print_data(Point&) in /home/niayan01/test_cpp_mangle)
    
        You can now use it in all perf tools, such as:
    
                perf record -e probe_test_cpp_mangle:test2 -aR sleep 1
    
    Fixes: fb1587d869a3 ("perf probe: List probes with line number and file name")
    Signed-off-by: Leo Yan <leo.yan@arm.com>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Link: https://lore.kernel.org/r/20241012141432.877894-1-leo.yan@arm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 918b71d6f1deadbd258241581fef98b51af94f0c
Author: Ian Rogers <irogers@google.com>
Date:   Wed Oct 16 16:56:22 2024 -0700

    perf probe: Fix libdw memory leak
    
    [ Upstream commit 4585038b8e186252141ef86e9f0d8e97f11dce8d ]
    
    Add missing dwarf_cfi_end to free memory associated with probe_finder
    cfi_eh which is allocated and owned via a call to
    dwarf_getcfi_elf. Confusingly cfi_dbg shouldn't be freed as its memory
    is owned by the passed in debuginfo struct. Add comments to highlight
    this.
    
    This addresses leak sanitizer issues seen in:
    tools/perf/tests/shell/test_uprobe_from_different_cu.sh
    
    Fixes: 270bde1e76f4 ("perf probe: Search both .eh_frame and .debug_frame sections for probe location")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Steinar H. Gunderson <sesse@google.com>
    Cc: Alexander Lobakin <aleksander.lobakin@intel.com>
    Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
    Link: https://lore.kernel.org/r/20241016235622.52166-3-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e58b2987960efcd917bc42da781cee256213618
Author: Chao Yu <chao@kernel.org>
Date:   Tue Oct 15 11:43:39 2024 +0800

    f2fs: fix to account dirty data in __get_secs_required()
    
    [ Upstream commit 1acd73edbbfef2c3c5b43cba4006a7797eca7050 ]
    
    It will trigger system panic w/ testcase in [1]:
    
    ------------[ cut here ]------------
    kernel BUG at fs/f2fs/segment.c:2752!
    RIP: 0010:new_curseg+0xc81/0x2110
    Call Trace:
     f2fs_allocate_data_block+0x1c91/0x4540
     do_write_page+0x163/0xdf0
     f2fs_outplace_write_data+0x1aa/0x340
     f2fs_do_write_data_page+0x797/0x2280
     f2fs_write_single_data_page+0x16cd/0x2190
     f2fs_write_cache_pages+0x994/0x1c80
     f2fs_write_data_pages+0x9cc/0xea0
     do_writepages+0x194/0x7a0
     filemap_fdatawrite_wbc+0x12b/0x1a0
     __filemap_fdatawrite_range+0xbb/0xf0
     file_write_and_wait_range+0xa1/0x110
     f2fs_do_sync_file+0x26f/0x1c50
     f2fs_sync_file+0x12b/0x1d0
     vfs_fsync_range+0xfa/0x230
     do_fsync+0x3d/0x80
     __x64_sys_fsync+0x37/0x50
     x64_sys_call+0x1e88/0x20d0
     do_syscall_64+0x4b/0x110
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    The root cause is if checkpoint_disabling and lfs_mode are both on,
    it will trigger OPU for all overwritten data, it may cost more free
    segment than expected, so f2fs must account those data correctly to
    calculate cosumed free segments later, and return ENOSPC earlier to
    avoid run out of free segment during block allocation.
    
    [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/
    
    Fixes: 4354994f097d ("f2fs: checkpoint disabling")
    Cc: Daniel Rosenberg <drosen@google.com>
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6e617c111092746d2370686ca880b8a78d8e249
Author: Qi Han <hanqi@vivo.com>
Date:   Sun Sep 29 02:00:10 2024 -0600

    f2fs: compress: fix inconsistent update of i_blocks in release_compress_blocks and reserve_compress_blocks
    
    [ Upstream commit 26413ce18e85de3dda2cd3d72c3c3e8ab8f4f996 ]
    
    After release a file and subsequently reserve it, the FSCK flag is set
    when the file is deleted, as shown in the following backtrace:
    
    F2FS-fs (dm-48): Inconsistent i_blocks, ino:401231, iblocks:1448, sectors:1472
    fs_rec_info_write_type+0x58/0x274
    f2fs_rec_info_write+0x1c/0x2c
    set_sbi_flag+0x74/0x98
    dec_valid_block_count+0x150/0x190
    f2fs_truncate_data_blocks_range+0x2d4/0x3cc
    f2fs_do_truncate_blocks+0x2fc/0x5f0
    f2fs_truncate_blocks+0x68/0x100
    f2fs_truncate+0x80/0x128
    f2fs_evict_inode+0x1a4/0x794
    evict+0xd4/0x280
    iput+0x238/0x284
    do_unlinkat+0x1ac/0x298
    __arm64_sys_unlinkat+0x48/0x68
    invoke_syscall+0x58/0x11c
    
    For clusters of the following type, i_blocks are decremented by 1 and
    i_compr_blocks are incremented by 7 in release_compress_blocks, while
    updates to i_blocks and i_compr_blocks are skipped in reserve_compress_blocks.
    
    raw node:
    D D D D D D D D
    after compress:
    C D D D D D D D
    after reserve:
    C D D D D D D D
    
    Let's update i_blocks and i_compr_blocks properly in reserve_compress_blocks.
    
    Fixes: eb8fbaa53374 ("f2fs: compress: fix to check unreleased compressed cluster")
    Signed-off-by: Qi Han <hanqi@vivo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d41eb5bfa1385c7a12ab3b46658283b73b5e067
Author: Ian Rogers <irogers@google.com>
Date:   Mon Sep 30 22:23:24 2024 -0700

    perf stat: Fix affinity memory leaks on error path
    
    [ Upstream commit 7f6ccb70e465bd8c9cf8973aee1c01224e4bdb3c ]
    
    Missed cleanup when an error occurs.
    
    Fixes: 49de179577e7 ("perf stat: No need to setup affinities when starting a workload")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Link: https://lore.kernel.org/r/20241001052327.7052-2-irogers@google.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4b553cc5c7999ded06da96b3f1a81d2f4ac1355
Author: Levi Yun <yeoreum.yun@arm.com>
Date:   Wed Sep 25 14:20:21 2024 +0100

    perf stat: Close cork_fd when create_perf_stat_counter() failed
    
    [ Upstream commit e880a70f8046df0dd9089fa60dcb866a2cc69194 ]
    
    When create_perf_stat_counter() failed, it doesn't close workload.cork_fd
    open in evlist__prepare_workload(). This could make too many open file
    error while __run_perf_stat() repeats.
    
    Introduce evlist__cancel_workload to close workload.cork_fd and
    wait workload.child_pid until exit to clear child process
    when create_perf_stat_counter() is failed.
    
    Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
    Reviewed-by: James Clark <james.clark@linaro.org>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Cc: nd@arm.com
    Cc: howardchu95@gmail.com
    Link: https://lore.kernel.org/r/20240925132022.2650180-2-yeoreum.yun@arm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Stable-dep-of: 7f6ccb70e465 ("perf stat: Fix affinity memory leaks on error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 931d07ccffcc3614f20aaf602b31e89754e21c59
Author: Todd Kjos <tkjos@google.com>
Date:   Tue Oct 1 23:11:47 2024 +0000

    PCI: Fix reset_method_store() memory leak
    
    [ Upstream commit 2985b1844f3f3447f2d938eff1ef6762592065a5 ]
    
    In reset_method_store(), a string is allocated via kstrndup() and assigned
    to the local "options". options is then used in with strsep() to find
    spaces:
    
      while ((name = strsep(&options, " ")) != NULL) {
    
    If there are no remaining spaces, then options is set to NULL by strsep(),
    so the subsequent kfree(options) doesn't free the memory allocated via
    kstrndup().
    
    Fix by using a separate tmp_options to iterate with strsep() so options is
    preserved.
    
    Link: https://lore.kernel.org/r/20241001231147.3583649-1-tkjos@google.com
    Fixes: d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism")
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fe12d6bf73ac4a5ef08334b28db30bcb029c357
Author: James Clark <james.clark@linaro.org>
Date:   Mon Sep 16 14:57:32 2024 +0100

    perf cs-etm: Don't flush when packet_queue fills up
    
    [ Upstream commit 5afd032961e8465808c4bc385c06e7676fbe1951 ]
    
    cs_etm__flush(), like cs_etm__sample() is an operation that generates a
    sample and then swaps the current with the previous packet. Calling
    flush after processing the queues results in two swaps which corrupts
    the next sample. Therefore it wasn't appropriate to call flush here so
    remove it.
    
    Flushing is still done on a discontinuity to explicitly clear the last
    branch buffer, but when the packet_queue fills up before reaching a
    timestamp, that's not a discontinuity and the call to
    cs_etm__process_traceid_queue() already generated samples and drained
    the buffers correctly.
    
    This is visible by looking for a branch that has the same target as the
    previous branch and the following source is before the address of the
    last target, which is impossible as execution would have had to have
    gone backwards:
    
      ffff800080849d40 _find_next_and_bit+0x78 => ffff80008011cadc update_sg_lb_stats+0x94
       (packet_queue fills here before a timestamp, resulting in a flush and
        branch target ffff80008011cadc is duplicated.)
      ffff80008011cb1c update_sg_lb_stats+0xd4 => ffff80008011cadc update_sg_lb_stats+0x94
      ffff8000801117c4 cpu_util+0x24 => ffff8000801117d4 cpu_util+0x34
    
    After removing the flush the correct branch target is used for the
    second sample, and ffff8000801117c4 is no longer before the previous
    address:
    
      ffff800080849d40 _find_next_and_bit+0x78 => ffff80008011cadc update_sg_lb_stats+0x94
      ffff80008011cb1c update_sg_lb_stats+0xd4 => ffff8000801117a0 cpu_util+0x0
      ffff8000801117c4 cpu_util+0x24 => ffff8000801117d4 cpu_util+0x34
    
    Make sure that a final branch stack is output at the end of the trace
    by calling cs_etm__end_block(). This is already done for both the
    timeless decode paths.
    
    Fixes: 21fe8dc1191a ("perf cs-etm: Add support for CPU-wide trace scenarios")
    Reported-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
    Closes: https://lore.kernel.org/all/20240719092619.274730-1-gankulkarni@os.amperecomputing.com/
    Reviewed-by: Leo Yan <leo.yan@arm.com>
    Signed-off-by: James Clark <james.clark@linaro.org>
    Tested-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
    Cc: Ben Gainey <ben.gainey@arm.com>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Ruidong Tian <tianruidong@linux.alibaba.com>
    Cc: Benjamin Gray <bgray@linux.ibm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: coresight@lists.linaro.org
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: scclevenger@os.amperecomputing.com
    Link: https://lore.kernel.org/r/20240916135743.1490403-2-james.clark@linaro.org
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04eef38c53b1ea101222f751de4b82e2bc1994a3
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Nov 14 12:00:12 2024 +0300

    mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()
    
    [ Upstream commit 192a16a3430ca459c4e986f3d10758c4d6b1aa29 ]
    
    Both the inner and outer loops in this code use the "i" iterator.
    The inner loop should really use a different iterator.
    
    It doesn't affect things in practice because the data comes from the
    device tree.  The "protocol" and "windows" variables are going to be
    zero.  That means we're always going to hit the "return &chans[channel];"
    statement and we're not going to want to iterate through the outer
    loop again.
    
    Still it's worth fixing this for future use cases.
    
    Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd2a4e32aaf90f16c1392b6860ef2329f101a202
Author: Paul Aurich <paul@darkrain42.org>
Date:   Fri Nov 8 14:29:02 2024 -0800

    smb: cached directories can be more than root file handle
    
    [ Upstream commit 128630e1dbec8074c7707aad107299169047e68f ]
    
    Update this log message since cached fids may represent things other
    than the root of a mount.
    
    Fixes: e4029e072673 ("cifs: find and use the dentry for cached non-root directories also")
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    Reviewed-by: Bharath SM <bharathsm@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07fdc5160470f33481e4fe4d0523a42eefde7cff
Author: zhang jiao <zhangjiao2@cmss.chinamobile.com>
Date:   Wed Nov 13 15:12:01 2024 +0800

    pinctrl: k210: Undef K210_PC_DEFAULT
    
    [ Upstream commit 7e86490c5dee5c41a55f32d0dc34269e200e6909 ]
    
    When the temporary macro K210_PC_DEFAULT is not needed anymore,
    use its name in the #undef statement instead of
    the incorrect "DEFAULT" name.
    
    Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver")
    Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Link: https://lore.kernel.org/20241113071201.5440-1-zhangjiao2@cmss.chinamobile.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08c494c1981ea61c2889526933515dd46feb6a21
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Tue Oct 29 14:59:42 2024 +0100

    clk: clk-axi-clkgen: make sure to enable the AXI bus clock
    
    [ Upstream commit c64ef7e4851d1a9abbb7f7833e4936973ac5ba79 ]
    
    In order to access the registers of the HW, we need to make sure that
    the AXI bus clock is enabled. Hence let's increase the number of clocks
    by one.
    
    In order to keep backward compatibility and make sure old DTs still work
    we check if clock-names is available or not. If it is, then we can
    disambiguate between really having the AXI clock or a parent clock and
    so we can enable the bus clock. If not, we fallback to what was done
    before and don't explicitly enable the AXI bus clock.
    
    Note that if clock-names is given, the axi clock must be the last one in
    the phandle array (also enforced in the DT bindings) so that we can reuse
    as much code as possible.
    
    Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-2-bc5e0733ad76@analog.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9b1bd1e1ec3381ef7ee46f34803ad3025cf6241
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Tue Oct 29 14:59:41 2024 +0100

    dt-bindings: clock: axi-clkgen: include AXI clk
    
    [ Upstream commit 47f3f5a82a31527e027929c5cec3dd1ef5ef30f5 ]
    
    In order to access the registers of the HW, we need to make sure that
    the AXI bus clock is enabled. Hence let's increase the number of clocks
    by one and add clock-names to differentiate between parent clocks and
    the bus clock.
    
    Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-1-bc5e0733ad76@analog.com
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a5905b725739af6a105f9e564e7c80d69969d2b
Author: Charles Han <hanchunchao@inspur.com>
Date:   Thu Nov 14 15:28:20 2024 +0800

    clk: clk-apple-nco: Add NULL check in applnco_probe
    
    [ Upstream commit 969c765e2b508cca9099d246c010a1e48dcfd089 ]
    
    Add NULL check in applnco_probe, to handle kernel NULL pointer
    dereference error.
    
    Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO")
    Signed-off-by: Charles Han <hanchunchao@inspur.com>
    Link: https://lore.kernel.org/r/20241114072820.3071-1-hanchunchao@inspur.com
    Reviewed-by: Martin Povišer <povik+lin@cutebit.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40f4326ed05a3b3537556ff2a844958b9e779a98
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat Oct 26 11:56:34 2024 +0800

    fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
    
    [ Upstream commit f89d17ae2ac42931be2a0153fecbf8533280c927 ]
    
    When information such as info->screen_base is not ready, calling
    sh7760fb_free_mem() does not release memory correctly. Call
    dma_free_coherent() instead.
    
    Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30293309efd5c956de13a3122f4d2047981f98a8
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Tue Jun 13 13:07:02 2023 +0200

    fbdev/sh7760fb: Alloc DMA memory from hardware device
    
    [ Upstream commit 8404e56f4bc1d1a65bfc98450ba3dae5e653dda1 ]
    
    Pass the hardware device to the DMA helpers dma_alloc_coherent() and
    dma_free_coherent(). The fbdev device that is currently being used is
    a software device and does not provide DMA memory. Also update the
    related dev_*() output statements similarly.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-28-tzimmermann@suse.de
    Stable-dep-of: f89d17ae2ac4 ("fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d9f5e40ffc6fa357ddbb947f4d86d352b49573d
Author: Zhang Zekun <zhangzekun11@huawei.com>
Date:   Mon Sep 30 15:56:28 2024 +0800

    powerpc/kexec: Fix return of uninitialized variable
    
    [ Upstream commit 83b5a407fbb73e6965adfb4bd0a803724bf87f96 ]
    
    of_property_read_u64() can fail and leave the variable uninitialized,
    which will then be used. Return error if reading the property failed.
    
    Fixes: 2e6bd221d96f ("powerpc/kexec_file: Enable early kernel OPAL calls")
    Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20240930075628.125138-1-zhangzekun11@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ad49b3c532634d04d93a725b8b35cea838525a6
Author: Michal Suchanek <msuchanek@suse.de>
Date:   Tue Oct 1 15:03:49 2024 +0200

    powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static
    
    [ Upstream commit a26c4dbb3d9c1821cb0fc11cb2dbc32d5bf3463b ]
    
    These functions are not used outside of sstep.c
    
    Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code")
    Signed-off-by: Michal Suchanek <msuchanek@suse.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241001130356.14664-1-msuchanek@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f99cc5112ff32ab7cdfbd9c7d94e1608e66c4c79
Author: Gautam Menghani <gautam@linux.ibm.com>
Date:   Sat Nov 9 12:02:57 2024 +0530

    KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending doorbells
    
    [ Upstream commit 26686db69917399fa30e3b3135360771e90f83ec ]
    
    Commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes")
    dropped the use of vcore->dpdes for msgsndp / SMT emulation. Prior to that
    commit, the below code at L1 level (see [1] for terminology) was
    responsible for setting vc->dpdes for the respective L2 vCPU:
    
    if (!nested) {
            kvmppc_core_prepare_to_enter(vcpu);
            if (vcpu->arch.doorbell_request) {
                    vc->dpdes = 1;
                    smp_wmb();
                    vcpu->arch.doorbell_request = 0;
            }
    
    L1 then sent vc->dpdes to L0 via kvmhv_save_hv_regs(), and while
    servicing H_ENTER_NESTED at L0, the below condition at L0 level made sure
    to abort and go back to L1 if vcpu->arch.doorbell_request = 1 so that L1
    sets vc->dpdes as per above if condition:
    
    } else if (vcpu->arch.pending_exceptions ||
               vcpu->arch.doorbell_request ||
               xive_interrupt_pending(vcpu)) {
            vcpu->arch.ret = RESUME_HOST;
            goto out;
    }
    
    This worked fine since vcpu->arch.doorbell_request was used more like a
    flag and vc->dpdes was used to pass around the doorbell state. But after
    Commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes"),
    vcpu->arch.doorbell_request is the only variable used to pass around
    doorbell state.
    With the plumbing for handling doorbells for nested guests updated to use
    vcpu->arch.doorbell_request over vc->dpdes, the above "else if" stops
    doorbells from working correctly as L0 aborts execution of L2 and
    instead goes back to L1.
    
    Remove vcpu->arch.doorbell_request from the above "else if" condition as
    it is no longer needed for L0 to correctly handle the doorbell status
    while running L2.
    
    [1] Terminology
    1. L0 : PowerNV linux running with HV privileges
    2. L1 : Pseries KVM guest running on top of L0
    2. L2 : Nested KVM guest running on top of L1
    
    Fixes: 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes")
    Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241109063301.105289-4-gautam@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a6e47dc0079c3d2b2f006fc6456c61f47857f23
Author: Gautam Menghani <gautam@linux.ibm.com>
Date:   Sat Nov 9 12:02:56 2024 +0530

    KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests
    
    [ Upstream commit 0d3c6b28896f9889c8864dab469e0343a0ad1c0c ]
    
    commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes")
    introduced an optimization to use only vcpu->doorbell_request for SMT
    emulation for Power9 and above guests, but the code for nested guests
    still relies on the old way of handling doorbells, due to which an L2
    guest (see [1]) cannot be booted with XICS with SMT>1. The command to
    repro this issue is:
    
    // To be run in L1
    
    qemu-system-ppc64 \
            -drive file=rhel.qcow2,format=qcow2 \
            -m 20G \
            -smp 8,cores=1,threads=8 \
            -cpu  host \
            -nographic \
            -machine pseries,ic-mode=xics -accel kvm
    
    Fix the plumbing to utilize vcpu->doorbell_request instead of vcore->dpdes
    for nested KVM guests on P9 and above.
    
    [1] Terminology
    1. L0 : PowerNV linux running with HV privileges
    2. L1 : Pseries KVM guest running on top of L0
    2. L2 : Nested KVM guest running on top of L1
    
    Fixes: 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes")
    Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241109063301.105289-3-gautam@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac2ec07ce6c79878e3c219555d86eacc303ccf1e
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Thu Oct 17 03:11:25 2024 -0700

    dax: delete a stale directory pmem
    
    [ Upstream commit b8e6d7ce50673c39514921ac61f7af00bbb58b87 ]
    
    After commit: 83762cb5c7c4 ("dax: Kill DEV_DAX_PMEM_COMPAT") the pmem/
    directory is not needed anymore and Makefile changes were made
    accordingly in this commit, but there is a Makefile and pmem.c in pmem/
    which are now stale and pmem.c is empty, remove them.
    
    Fixes: 83762cb5c7c4 ("dax: Kill DEV_DAX_PMEM_COMPAT")
    Suggested-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Link: https://patch.msgid.link/20241017101144.1654085-1-harshit.m.mogalapalli@oracle.com
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83f8713a0ef1d55d6a287bcfadcaab8245ac5098
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Oct 29 12:17:36 2024 +0300

    ocfs2: fix uninitialized value in ocfs2_file_read_iter()
    
    [ Upstream commit adc77b19f62d7e80f98400b2fca9d700d2afdd6f ]
    
    Syzbot has reported the following KMSAN splat:
    
    BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80
     ocfs2_file_read_iter+0x9a4/0xf80
     __io_read+0x8d4/0x20f0
     io_read+0x3e/0xf0
     io_issue_sqe+0x42b/0x22c0
     io_wq_submit_work+0xaf9/0xdc0
     io_worker_handle_work+0xd13/0x2110
     io_wq_worker+0x447/0x1410
     ret_from_fork+0x6f/0x90
     ret_from_fork_asm+0x1a/0x30
    
    Uninit was created at:
     __alloc_pages_noprof+0x9a7/0xe00
     alloc_pages_mpol_noprof+0x299/0x990
     alloc_pages_noprof+0x1bf/0x1e0
     allocate_slab+0x33a/0x1250
     ___slab_alloc+0x12ef/0x35e0
     kmem_cache_alloc_bulk_noprof+0x486/0x1330
     __io_alloc_req_refill+0x84/0x560
     io_submit_sqes+0x172f/0x2f30
     __se_sys_io_uring_enter+0x406/0x41c0
     __x64_sys_io_uring_enter+0x11f/0x1a0
     x64_sys_call+0x2b54/0x3ba0
     do_syscall_64+0xcd/0x1e0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Since an instance of 'struct kiocb' may be passed from the block layer
    with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'
    and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in
    'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.
    
    Link: https://lkml.kernel.org/r/20241029091736.1501946-1-dmantipov@yandex.ru
    Fixes: 7cdfc3a1c397 ("ocfs2: Remember rw lock level during direct io")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Reported-by: syzbot+a73e253cca4f0230a5a5@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=a73e253cca4f0230a5a5
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <jiangqi903@gmail.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 678098cef6459206ac0375bc5fed089db0bdbe43
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Nov 6 09:01:11 2024 +0800

    cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()
    
    [ Upstream commit b51eb0874d8170028434fbd259e80b78ed9b8eca ]
    
    cppc_get_cpu_power() return 0 if the policy is NULL. Then in
    em_create_perf_table(), the later zero check for power is not valid
    as power is uninitialized. As Quentin pointed out, kernel energy model
    core check the return value of active_power() first, so if the callback
    failed it should tell the core. So return -EINVAL to fix it.
    
    Fixes: a78e72075642 ("cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Suggested-by: Quentin Perret <qperret@google.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ef0b11af70799f96588c2aca36fff8d5ce25c7b
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Nov 6 09:12:38 2024 +0800

    cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()
    
    [ Upstream commit be392aa80f1e5b0b65ccc2a540b9304fefcfe3d8 ]
    
    cppc_get_cpu_cost() return 0 if the policy is NULL. Then in
    em_compute_costs(), the later zero check for cost is not valid
    as cost is uninitialized. As Quentin pointed out, kernel energy model
    core check the return value of get_cost() first, so if the callback
    failed it should tell the core. Return -EINVAL to fix it.
    
    Fixes: 1a1374bb8c59 ("cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/c4765377-7830-44c2-84fa-706b6e304e10@stanley.mountain/
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Suggested-by: Quentin Perret <qperret@google.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52617e76f4963644db71dc0a17e998654dc0c7f4
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Fri Nov 8 15:57:43 2024 +0800

    RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
    
    [ Upstream commit 6b526d17eed850352d880b93b9bf20b93006bd92 ]
    
    ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.
    The driver needs to check whether it is a NULL pointer before
    dereferencing it.
    
    Fixes: d387d4b54eb8 ("RDMA/hns: Fix missing pagesize and alignment check in FRMR")
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://patch.msgid.link/20241108075743.2652258-3-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 630c6b9116dd0251a66f9be95e3042893a297b21
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Fri Nov 8 15:57:42 2024 +0800

    RDMA/hns: Fix out-of-order issue of requester when setting FENCE
    
    [ Upstream commit 5dbcb1c1900f45182b5651c89257c272f1f3ead7 ]
    
    The FENCE indicator in hns WQE doesn't ensure that response data from
    a previous Read/Atomic operation has been written to the requester's
    memory before the subsequent Send/Write operation is processed. This
    may result in the subsequent Send/Write operation accessing the original
    data in memory instead of the expected response data.
    
    Unlike FENCE, the SO (Strong Order) indicator blocks the subsequent
    operation until the previous response data is written to memory and a
    bresp is returned. Set the SO indicator instead of FENCE to maintain
    strict order.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://patch.msgid.link/20241108075743.2652258-2-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b778b5240485106abf665eb509cc01779ed0cb00
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat Oct 26 20:57:11 2024 +0800

    scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()
    
    [ Upstream commit 95bbdca4999bc59a72ebab01663d421d6ce5775d ]
    
    Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA
    memory sb_virt when it fails. Add dma_free_coherent() to free it. This
    is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
    
    Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20241026125711.484-3-thunder.leizhen@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b514f45e0fe18d763a1afc34401b1585333cb329
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat Oct 26 20:57:10 2024 +0800

    scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()
    
    [ Upstream commit c62c30429db3eb4ced35c7fcf6f04a61ce3a01bb ]
    
    Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA
    memory sb_virt when it fails. Add dma_free_coherent() to free it. This
    is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20241026125711.484-2-thunder.leizhen@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31f29289c7eace62a29007bf00e09a6d8339ad7e
Author: Zeng Heng <zengheng4@huawei.com>
Date:   Thu Oct 24 16:44:17 2024 +0800

    scsi: fusion: Remove unused variable 'rc'
    
    [ Upstream commit bd65694223f7ad11c790ab63ad1af87a771192ee ]
    
    The return value of scsi_device_reprobe() is currently ignored in
    _scsih_reprobe_lun(). Fixing the calling code to deal with the potential
    error is non-trivial, so for now just WARN_ON().
    
    The handling of scsi_device_reprobe()'s return value refers to
    _scsih_reprobe_lun() and the following link:
    
    https://lore.kernel.org/all/094fdbf57487af4f395238c0525b2a560c8f68f0.1469766027.git.calvinowens@fb.com/
    
    Fixes: f99be43b3024 ("[SCSI] fusion: power pc and miscellaneous bug fixs")
    Signed-off-by: Zeng Heng <zengheng4@huawei.com>
    Link: https://lore.kernel.org/r/20241024084417.154655-1-zengheng4@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f5a97443b547b4c83f876f1d6a11df0f1fd4efb
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Oct 23 09:18:09 2024 +0800

    scsi: bfa: Fix use-after-free in bfad_im_module_exit()
    
    [ Upstream commit 178b8f38932d635e90f5f0e9af1986c6f4a89271 ]
    
    BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
    Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303
    
    Call Trace:
     <TASK>
     dump_stack_lvl+0x95/0xe0
     print_report+0xcb/0x620
     kasan_report+0xbd/0xf0
     __lock_acquire+0x2aca/0x3a20
     lock_acquire+0x19b/0x520
     _raw_spin_lock+0x2b/0x40
     attribute_container_unregister+0x30/0x160
     fc_release_transport+0x19/0x90 [scsi_transport_fc]
     bfad_im_module_exit+0x23/0x60 [bfa]
     bfad_init+0xdb/0xff0 [bfa]
     do_one_initcall+0xdc/0x550
     do_init_module+0x22d/0x6b0
     load_module+0x4e96/0x5ff0
     init_module_from_file+0xcd/0x130
     idempotent_init_module+0x330/0x620
     __x64_sys_finit_module+0xb3/0x110
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
     </TASK>
    
    Allocated by task 25303:
     kasan_save_stack+0x24/0x50
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0x7f/0x90
     fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]
     bfad_im_module_init+0x17/0x80 [bfa]
     bfad_init+0x23/0xff0 [bfa]
     do_one_initcall+0xdc/0x550
     do_init_module+0x22d/0x6b0
     load_module+0x4e96/0x5ff0
     init_module_from_file+0xcd/0x130
     idempotent_init_module+0x330/0x620
     __x64_sys_finit_module+0xb3/0x110
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 25303:
     kasan_save_stack+0x24/0x50
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     __kasan_slab_free+0x38/0x50
     kfree+0x212/0x480
     bfad_im_module_init+0x7e/0x80 [bfa]
     bfad_init+0x23/0xff0 [bfa]
     do_one_initcall+0xdc/0x550
     do_init_module+0x22d/0x6b0
     load_module+0x4e96/0x5ff0
     init_module_from_file+0xcd/0x130
     idempotent_init_module+0x330/0x620
     __x64_sys_finit_module+0xb3/0x110
     do_syscall_64+0xc1/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Above issue happens as follows:
    
    bfad_init
      error = bfad_im_module_init()
        fc_release_transport(bfad_im_scsi_transport_template);
      if (error)
        goto ext;
    
    ext:
      bfad_im_module_exit();
        fc_release_transport(bfad_im_scsi_transport_template);
        --> Trigger double release
    
    Don't call bfad_im_module_exit() if bfad_im_module_init() failed.
    
    Fixes: 7725ccfda597 ("[SCSI] bfa: Brocade BFA FC SCSI driver")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Link: https://lore.kernel.org/r/20241023011809.63466-1-yebin@huaweicloud.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41f80bdd5201a2969a47dd05d033a87ecce08c16
Author: Mirsad Todorovac <mtodorovac69@gmail.com>
Date:   Tue Oct 29 06:46:52 2024 +0100

    fs/proc/kcore.c: fix coccinelle reported ERROR instances
    
    [ Upstream commit 82e33f249f1126cf3c5f39a31b850d485ac33bc3 ]
    
    Coccinelle complains about the nested reuse of the pointer `iter' with
    different pointer type:
    
    ./fs/proc/kcore.c:515:26-30: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:534:23-27: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:550:40-44: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:568:27-31: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:581:28-32: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:599:27-31: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:607:38-42: ERROR: invalid reference to the index variable of the iterator on line 499
    ./fs/proc/kcore.c:614:26-30: ERROR: invalid reference to the index variable of the iterator on line 499
    
    Replacing `struct kcore_list *iter' with `struct kcore_list *tmp' doesn't change the
    scope and the functionality is the same and coccinelle seems happy.
    
    NOTE: There was an issue with using `struct kcore_list *pos' as the nested iterator.
          The build did not work!
    
    [akpm@linux-foundation.org: s/tmp/pos/]
    Link: https://lkml.kernel.org/r/20241029054651.86356-2-mtodorovac69@gmail.com
    Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1]
    Link: https://lkml.kernel.org/r/20220331223700.902556-1-jakobkoschel@gmail.com
    Fixes: 04d168c6d42d ("fs/proc/kcore.c: remove check of list iterator against head past the loop body")
    Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
    Signed-off-by: Mirsad Todorovac <mtodorovac69@gmail.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: "Brian Johannesmeyer" <bjohannesmeyer@gmail.com>
    Cc: Cristiano Giuffrida <c.giuffrida@vu.nl>
    Cc: "Bos, H.J." <h.j.bos@vu.nl>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Yang Li <yang.lee@linux.alibaba.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Hari Bathini <hbathini@linux.ibm.com>
    Cc: Yan Zhen <yanzhen@vivo.com>
    Cc: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d3b43738589254877482cc445e29f67942819a0
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Wed Oct 30 23:41:06 2024 +0800

    mfd: rt5033: Fix missing regmap_del_irq_chip()
    
    [ Upstream commit d256d612f47529ed0b332298e2d5ea981a4dd5b8 ]
    
    Fix missing call to regmap_del_irq_chip() in error handling path by
    using devm_regmap_add_irq_chip().
    
    Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1730302867-8391-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23a2a5770d524acce4769d2d8bede02c3c26c42a
Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
Date:   Mon Nov 4 09:40:33 2024 +0800

    iommu/vt-d: Fix checks and print in pgtable_walk()
    
    [ Upstream commit f1645676f25d2c846798f0233c3a953efd62aafb ]
    
    There are some issues in pgtable_walk():
    
    1. Super page is dumped as non-present page
    2. dma_pte_superpage() should not check against leaf page table entries
    3. Pointer pte is never NULL so checking it is meaningless
    4. When an entry is not present, it still makes sense to dump the entry
       content.
    
    Fix 1,2 by checking dma_pte_superpage()'s returned value after level check.
    Fix 3 by removing pte check.
    Fix 4 by checking present bit after printing.
    
    By this chance, change to print "page table not present" instead of "PTE
    not present" to be clearer.
    
    Fixes: 914ff7719e8a ("iommu/vt-d: Dump DMAR translation structure when DMA fault occurs")
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
    Link: https://lore.kernel.org/r/20241024092146.715063-3-zhenzhong.duan@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>

commit ef4a6cb5f22ce7f498810cbb784dc5e92414272b
Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
Date:   Mon Nov 4 09:40:32 2024 +0800

    iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()
    
    [ Upstream commit 6ceb93f952f6ca34823ce3650c902c31b8385b40 ]
    
    There are some issues in dmar_fault_dump_ptes():
    
    1. return value of phys_to_virt() is used for checking if an entry is
       present.
    2. dump is confusing, e.g., "pasid table entry is not present", confusing
       by unpresent pasid table vs. unpresent pasid table entry. Current code
       means the former.
    3. pgtable_walk() is called without checking if page table is present.
    
    Fix 1 by checking present bit of an entry before dump a lower level entry.
    Fix 2 by removing "entry" string, e.g., "pasid table is not present".
    Fix 3 by checking page table present before walk.
    
    Take issue 3 for example, before fix:
    
    [  442.240357] DMAR: pasid dir entry: 0x000000012c83e001
    [  442.246661] DMAR: pasid table entry[0]: 0x0000000000000000
    [  442.253429] DMAR: pasid table entry[1]: 0x0000000000000000
    [  442.260203] DMAR: pasid table entry[2]: 0x0000000000000000
    [  442.266969] DMAR: pasid table entry[3]: 0x0000000000000000
    [  442.273733] DMAR: pasid table entry[4]: 0x0000000000000000
    [  442.280479] DMAR: pasid table entry[5]: 0x0000000000000000
    [  442.287234] DMAR: pasid table entry[6]: 0x0000000000000000
    [  442.293989] DMAR: pasid table entry[7]: 0x0000000000000000
    [  442.300742] DMAR: PTE not present at level 2
    
    After fix:
    ...
    [  357.241214] DMAR: pasid table entry[6]: 0x0000000000000000
    [  357.248022] DMAR: pasid table entry[7]: 0x0000000000000000
    [  357.254824] DMAR: scalable mode page table is not present
    
    Fixes: 914ff7719e8a ("iommu/vt-d: Dump DMAR translation structure when DMA fault occurs")
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
    Link: https://lore.kernel.org/r/20241024092146.715063-2-zhenzhong.duan@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>

commit 6786d623fb01d32dd5635a5cb3a1ae42ae67848a
Author: Dong Aisheng <aisheng.dong@nxp.com>
Date:   Sun Oct 27 20:00:10 2024 +0800

    clk: imx: clk-scu: fix clk enable state save and restore
    
    [ Upstream commit e81361f6cf9bf4a1848b0813bc4becb2250870b8 ]
    
    The scu clk_ops only inplements prepare() and unprepare() callback.
    Saving the clock state during suspend by checking clk_hw_is_enabled()
    is not safe as it's possible that some device drivers may only
    disable the clocks without unprepare. Then the state retention will not
    work for such clocks.
    
    Fixing it by checking clk_hw_is_prepared() which is more reasonable
    and safe.
    
    Fixes: d0409631f466 ("clk: imx: scu: add suspend/resume support")
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Tested-by: Carlos Song <carlos.song@nxp.com>
    Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
    Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-4-89152574d1d7@nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 882d94d74694205b544b617c0bd88b307f6c0067
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Oct 27 20:00:09 2024 +0800

    clk: imx: fracn-gppll: fix pll power up
    
    [ Upstream commit ff4279618f0aec350b0fb41b2b35841324fbd96e ]
    
    To i.MX93 which features dual Cortex-A55 cores and DSU, when using
    writel_relaxed to write value to PLL registers, the value might be
    buffered. To make sure the value has been written into the hardware,
    using readl to read back the register could achieve the goal.
    
    current PLL power up flow can be simplified as below:
      1. writel_relaxed to set the PLL POWERUP bit;
      2. readl_poll_timeout to check the PLL lock bit:
         a). timeout = ktime_add_us(ktime_get(), timeout_us);
         b). readl the pll the lock reg;
         c). check if the pll lock bit ready
         d). check if timeout
    
    But in some corner cases, both the write in step 1 and read in
    step 2 will be blocked by other bus transaction in the SoC for a
    long time, saying the value into real hardware is just before step b).
    That means the timeout counting has begins for quite sometime since
    step a), but value still not written into real hardware until bus
    released just at a point before step b).
    
    Then there maybe chances that the pll lock bit is not ready
    when readl done but the timeout happens. readl_poll_timeout will
    err return due to timeout. To avoid such unexpected failure,
    read back the reg to make sure the write has been done in HW
    reg.
    
    So use readl after writel_relaxed to fix the issue.
    
    Since we are here, to avoid udelay to run before writel_relaxed, use
    readl before udelay.
    
    Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll")
    Co-developed-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-3-89152574d1d7@nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7aee64ed7ca994df8558a45f52532868092827c
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Oct 27 20:00:08 2024 +0800

    clk: imx: fracn-gppll: correct PLL initialization flow
    
    [ Upstream commit 557be501c38e1864b948fc6ccdf4b035d610a2ea ]
    
    Per i.MX93 Reference Mannual 22.4 Initialization information
    1. Program appropriate value of DIV[ODIV], DIV[RDIV] and DIV[MFI]
       as per Integer mode.
    2. Wait for 5 μs.
    3. Program the following field in CTRL register.
       Set CTRL[POWERUP] to 1'b1 to enable PLL block.
    4. Poll PLL_STATUS[PLL_LOCK] register, and wait till PLL_STATUS[PLL_LOCK]
       is 1'b1 and pll_lock output signal is 1'b1.
    5. Set CTRL[CLKMUX_EN] to 1'b1 to enable PLL output clock.
    
    So move the CLKMUX_EN operation after PLL locked.
    
    Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll")
    Co-developed-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-2-89152574d1d7@nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c92515247f613a510ed14a77fbdf27a9617b784a
Author: Peng Fan <peng.fan@nxp.com>
Date:   Sun Oct 27 20:00:07 2024 +0800

    clk: imx: lpcg-scu: SW workaround for errata (e10858)
    
    [ Upstream commit 5ee063fac85656bea9cfe3570af147ba1701ba18 ]
    
    Back-to-back LPCG writes can be ignored by the LPCG register due to
    a HW bug. The writes need to be separated by at least 4 cycles of
    the gated clock. See https://www.nxp.com.cn/docs/en/errata/IMX8_1N94W.pdf
    
    The workaround is implemented as follows:
    1. For clocks running greater than or equal to 24MHz, a read
    followed by the write will provide sufficient delay.
    2. For clocks running below 24MHz, add a delay of 4 clock cylces
    after the write to the LPCG register.
    
    Fixes: 2f77296d3df9 ("clk: imx: add lpcg clock support")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-1-89152574d1d7@nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b67ca853a27b09d3e140e9a2cce3c340568f4df
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Thu Oct 24 14:42:11 2024 +0100

    clk: renesas: rzg2l: Fix FOUTPOSTDIV clk
    
    [ Upstream commit dabf72b85f298970e86891b5218459c17b57b26a ]
    
    While computing foutpostdiv_rate, the value of params->pl5_fracin
    is discarded, which results in the wrong refresh rate. Fix the formula
    for computing foutpostdiv_rate.
    
    Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support")
    Signed-off-by: Hien Huynh <hien.huynh.px@renesas.com>
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/20241024134236.315289-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9bc7ccfbd31e2d8a20035eee1e6a853dec45cc66
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Tue Oct 1 11:50:16 2024 +0100

    clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset
    
    [ Upstream commit e0f253a52ccee3cf3eb987e99756e20c68a1aac9 ]
    
    To work around a limitation in our clock modelling, we try to force two
    bits in the AUDIO0 PLL to 0, in the CCU probe routine.
    However the ~ operator only applies to the first expression, and does
    not cover the second bit, so we end up clearing only bit 1.
    
    Group the bit-ORing with parentheses, to make it both clearer to read
    and actually correct.
    
    Fixes: 35b97bb94111 ("clk: sunxi-ng: Add support for the D1 SoC clocks")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Link: https://patch.msgid.link/20241001105016.1068558-1-andre.przywara@arm.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4799f3f8fd1450cf88ca5943d58193470e53c075
Author: Kashyap Desai <kashyap.desai@broadcom.com>
Date:   Mon Oct 28 03:06:54 2024 -0700

    RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey
    
    [ Upstream commit 808ca6de989c598bc5af1ae0ad971a66077efac0 ]
    
    Invalidate rkey is cpu endian and immediate data is in big endian format.
    Both immediate data and invalidate the remote key returned by
    HW is in little endian format.
    
    While handling the commit in fixes tag, the difference between
    immediate data and invalidate rkey endianness was not considered.
    
    Without changes of this patch, Kernel ULP was failing while processing
    inv_rkey.
    
    dmesg log snippet -
    nvme nvme0: Bogus remote invalidation for rkey 0x2000019Fix in this patch
    
    Do endianness conversion based on completion queue entry flag.
    Also, the HW completions are already converted to host endianness in
    bnxt_qplib_cq_process_res_rc and bnxt_qplib_cq_process_res_ud and there
    is no need to convert it again in bnxt_re_poll_cq. Modified the union to
    hold the correct data type.
    
    Fixes: 95b087f87b78 ("bnxt_re: Fix imm_data endianness")
    Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://patch.msgid.link/1730110014-20755-1-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31c6fe9b79ed42440094f2367897aea0c0ce96ec
Author: wenglianfa <wenglianfa@huawei.com>
Date:   Thu Oct 24 20:40:00 2024 +0800

    RDMA/hns: Fix cpu stuck caused by printings during reset
    
    [ Upstream commit 323275ac2ff15b2b7b3eac391ae5d8c5a3c3a999 ]
    
    During reset, cmd to destroy resources such as qp, cq, and mr may fail,
    and error logs will be printed. When a large number of resources are
    destroyed, there will be lots of printings, and it may lead to a cpu
    stuck.
    
    Delete some unnecessary printings and replace other printing functions
    in these paths with the ratelimited version.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode")
    Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
    Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC")
    Signed-off-by: wenglianfa <wenglianfa@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://patch.msgid.link/20241024124000.2931869-6-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 284a8650dfde5d4ae4e14698d6bcb633e27ab449
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Tue May 23 20:16:39 2023 +0800

    RDMA/hns: Remove unnecessary QP type checks
    
    [ Upstream commit b9989ab3f61ec459cbaf0a492fea3168bbfa4c7a ]
    
    It is not necessary to check the type of the queue on IO path because
    unsupported QP type cannot be created.
    
    Link: https://lore.kernel.org/r/20230523121641.3132102-2-huangjunxian6@hisilicon.com
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Stable-dep-of: 323275ac2ff1 ("RDMA/hns: Fix cpu stuck caused by printings during reset")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7519e81df8f0e26896704c7ada82429f1c0d062d
Author: Junxian Huang <huangjunxian6@hisilicon.com>
Date:   Thu Oct 24 20:39:59 2024 +0800

    RDMA/hns: Use dev_* printings in hem code instead of ibdev_*
    
    [ Upstream commit d81fb6511abf18591befaa5f4a972ffc838690ec ]
    
    The hem code is executed before ib_dev is registered, so use dev_*
    printing instead of ibdev_* to avoid log like this:
    
    (null): set HEM address to HW failed!
    
    Fixes: 2f49de21f3e9 ("RDMA/hns: Optimize mhop get flow for multi-hop addressing")
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://patch.msgid.link/20241024124000.2931869-5-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f42b87d0f5bb560515aa11707552395bae01957
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Tue May 23 20:16:41 2023 +0800

    RDMA/hns: Add clear_hem return value to log
    
    [ Upstream commit a519a612a71848b69b70b18b4d14d165b2d8aaf7 ]
    
    Log return value of clear_hem() to help diagnose.
    
    Link: https://lore.kernel.org/r/20230523121641.3132102-4-huangjunxian6@hisilicon.com
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Stable-dep-of: d81fb6511abf ("RDMA/hns: Use dev_* printings in hem code instead of ibdev_*")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 503d9576795466b1f376ae2e8315278b732e31d4
Author: wenglianfa <wenglianfa@huawei.com>
Date:   Thu Oct 24 20:39:56 2024 +0800

    RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci
    
    [ Upstream commit 571e4ab8a45e530623ab129803f090a844dd3fe9 ]
    
    eq_db_ci is updated only after all AEQEs are processed in the AEQ
    interrupt handler, which is not timely enough and may result in
    AEQ overflow. Two optimization methods are proposed:
    1. Set an upper limit for AEQE processing.
    2. Move time-consuming operations such as printings to the bottom
    half of the interrupt.
    
    cmd events and flush_cqe events are still fully processed in the top half
    to ensure timely handling.
    
    Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08")
    Signed-off-by: wenglianfa <wenglianfa@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://patch.msgid.link/20241024124000.2931869-2-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1975b481f644f8f841d9c188e3c214fce187f18b
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Oct 30 16:24:49 2024 +0800

    cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()
    
    [ Upstream commit 1a1374bb8c5926674973d849feed500bc61ad535 ]
    
    cpufreq_cpu_get_raw() may return NULL if the cpu is not in
    policy->cpus cpu mask and it will cause null pointer dereference,
    so check NULL for cppc_get_cpu_cost().
    
    Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a357b63fd21e4b2791008c2175ba7a8c235ebce1
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Oct 30 09:20:19 2024 +0800

    cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()
    
    [ Upstream commit a78e7207564258db6e373e86294a85f9d646d35a ]
    
    cpufreq_cpu_get_raw() may return NULL if the cpu is not in
    policy->cpus cpu mask and it will cause null pointer dereference.
    
    Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa5b5ea257135e771b489c83a2e93b5935d0108e
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Aug 19 22:24:01 2024 +1000

    powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore
    
    [ Upstream commit cadae3a45d23aa4f6485938a67cbc47aaaa25e38 ]
    
    The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
    the code calls kmalloc() while holding it, which can sleep:
    
      # echo 1 > /proc/powerpc/vcpudispatch_stats
      BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
      in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
      preempt_count: 1, expected: 0
      3 locks held by sh/199:
       #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
       #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
       #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
      CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152
      Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
      Call Trace:
        dump_stack_lvl+0x130/0x148 (unreliable)
        __might_resched+0x174/0x410
        kmem_cache_alloc_noprof+0x340/0x3d0
        alloc_dtl_buffers+0x124/0x1ac
        vcpudispatch_stats_write+0x2a8/0x5f4
        proc_reg_write+0xf4/0x150
        vfs_write+0xfc/0x438
        ksys_write+0x88/0x148
        system_call_exception+0x1c4/0x5a0
        system_call_common+0xf4/0x258
    
    Fixes: 06220d78f24a ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage")
    Tested-by: Kajol Jain <kjain@linux.ibm.com>
    Reviewed-by: Nysal Jan K.A <nysal@linux.ibm.com>
    Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20240819122401.513203-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d2655754e94741b159aa807b72ea85518a65fd5
Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Date:   Fri Oct 18 22:59:42 2024 +0530

    powerpc/mm/fault: Fix kfence page fault reporting
    
    [ Upstream commit 06dbbb4d5f7126b6307ab807cbf04ecfc459b933 ]
    
    copy_from_kernel_nofault() can be called when doing read of /proc/kcore.
    /proc/kcore can have some unmapped kfence objects which when read via
    copy_from_kernel_nofault() can cause page faults. Since *_nofault()
    functions define their own fixup table for handling fault, use that
    instead of asking kfence to handle such faults.
    
    Hence we search the exception tables for the nip which generated the
    fault. If there is an entry then we let the fixup table handler handle the
    page fault by returning an error from within ___do_page_fault().
    
    This can be easily triggered if someone tries to do dd from /proc/kcore.
    eg. dd if=/proc/kcore of=/dev/null bs=1M
    
    Some example false negatives:
    
      ===============================
      BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0
      Invalid read at 0xc0000000fdff0000:
       copy_from_kernel_nofault+0x9c/0x1a0
       0xc00000000665f950
       read_kcore_iter+0x57c/0xa04
       proc_reg_read_iter+0xe4/0x16c
       vfs_read+0x320/0x3ec
       ksys_read+0x90/0x154
       system_call_exception+0x120/0x310
       system_call_vectored_common+0x15c/0x2ec
    
      BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0
      Use-after-free read at 0xc0000000fe050000 (in kfence-#2):
       copy_from_kernel_nofault+0x9c/0x1a0
       0xc00000000665f950
       read_kcore_iter+0x57c/0xa04
       proc_reg_read_iter+0xe4/0x16c
       vfs_read+0x320/0x3ec
       ksys_read+0x90/0x154
       system_call_exception+0x120/0x310
       system_call_vectored_common+0x15c/0x2ec
    
    Fixes: 90cbac0e995d ("powerpc: Enable KFENCE for PPC32")
    Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Reported-by: Disha Goel <disgoel@linux.ibm.com>
    Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/a411788081d50e3b136c6270471e35aba3dfafa3.1729271995.git.ritesh.list@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24cbc37e837fd9e31e5024480b779207d1d99f1d
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Oct 1 22:31:49 2024 +0200

    mtd: rawnand: atmel: Fix possible memory leak
    
    [ Upstream commit 6d734f1bfc336aaea91313a5632f2f197608fadd ]
    
    The pmecc "user" structure is allocated in atmel_pmecc_create_user() and
    was supposed to be freed with atmel_pmecc_destroy_user(), but this other
    helper is never called. One solution would be to find the proper
    location to call the destructor, but the trend today is to switch to
    device managed allocations, which in this case fits pretty well.
    
    Replace kzalloc() by devm_kzalloc() and drop the destructor entirely.
    
    Reported-by: "Dr. David Alan Gilbert" <linux@treblig.org>
    Closes: https://lore.kernel.org/all/ZvmIvRJCf6VhHvpo@gallifrey/
    Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20241001203149.387655-1-miquel.raynal@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57d385c07fd410a9631cd87b6b73e0dc1f3cab87
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Wed Jul 31 09:08:40 2024 +0100

    mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 7d189579a287d5c568db623c5fc2344cce98a887 ]
    
    The rpc-if-hyperflash driver can be compiled as a module, but lacks
    MODULE_DEVICE_TABLE() and will therefore not be loaded automatically.
    Fix this.
    
    Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240731080846.257139-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dff61d85bc979b12dfd6a7cf78d06a80472ec9de
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Oct 8 22:01:33 2023 +0200

    mtd: hyperbus: rpc-if: Convert to platform remove callback returning void
    
    [ Upstream commit baaa90c1c923ff2412fae0162eb66d036fd3be6b ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is ignored (apart
    from emitting a warning) and this typically results in resource leaks.
    
    To improve here there is a quest to make the remove callback return
    void. In the first step of this quest all drivers are converted to
    .remove_new(), which already returns void. Eventually after all drivers
    are converted, .remove_new() will be renamed to .remove().
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-11-u.kleine-koenig@pengutronix.de
    Stable-dep-of: 7d189579a287 ("mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0222dbbf645c91e50a26495c729f4e2f3cf12ec
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Nov 23 15:41:22 2022 +0100

    memory: renesas-rpc-if: Remove Runtime PM wrappers
    
    [ Upstream commit 27e5f98c30d73cdb8c8baeaf7d0af19af5266d3a ]
    
    Now the rpcif_{en,dis}able_rpm() wrappers just take a pointer to a
    device structure, there is no point in keeping them.  Remove them, and
    update the callers to call Runtime PM directly.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/d87aa5d7e4a39b18f7e2e0649fee0a45b45d371f.1669213027.git.geert+renesas@glider.be
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Stable-dep-of: 7d189579a287 ("mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f025336fd88403d0ff078acb28dffe7c52ba0f69
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Nov 23 15:41:21 2022 +0100

    memory: renesas-rpc-if: Pass device instead of rpcif to rpcif_*()
    
    [ Upstream commit a198fcd1d53cbaf616d94822921c77910b94edb7 ]
    
    Most rpcif_*() API functions do not need access to any other fields in
    the rpcif structure than the device pointer.  Simplify dependencies by
    passing the device pointer instead.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/0460fe82ba348cedec7a9a75a8eff762c50e817b.1669213027.git.geert+renesas@glider.be
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Stable-dep-of: 7d189579a287 ("mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7ef1b97ce09d79653b2e19a7d679178e062db05
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Nov 23 15:41:20 2022 +0100

    memory: renesas-rpc-if: Improve Runtime PM handling
    
    [ Upstream commit bb0b025d72d22b8617df920b61f5ae1e23d1b593 ]
    
    Convert from the deprecated pm_runtime_get_sync() to the new
    pm_runtime_resume_and_get(), and add error checking.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/6f2bd3b2b3d98c5bed541d969900b2ad04f93943.1669213027.git.geert+renesas@glider.be
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Stable-dep-of: 7d189579a287 ("mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aabef6301dcf410dfd2b8759cd413b2a003c7e3f
Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Date:   Fri Oct 18 21:47:57 2024 +0530

    powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()
    
    [ Upstream commit 05b94cae1c47f94588c3e7096963c1007c4d9c1d ]
    
    During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,
    since pageblock_order is still zero and it gets initialized
    later during initmem_init() e.g.
    setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order()
    
    One such use case where this causes issue is -
    early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init()
    
    This causes CMA memory alignment check to be bypassed in
    cma_init_reserved_mem(). Then later cma_activate_area() can hit
    a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory
    area was not pageblock_order aligned.
    
    Fix it by moving the fadump_cma_init() after initmem_init(),
    where other such cma reservations also gets called.
    
    <stack trace>
    ==============
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010
    flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA
    raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000
    raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1))
    ------------[ cut here ]------------
    kernel BUG at mm/page_alloc.c:778!
    
    Call Trace:
    __free_one_page+0x57c/0x7b0 (unreliable)
    free_pcppages_bulk+0x1a8/0x2c8
    free_unref_page_commit+0x3d4/0x4e4
    free_unref_page+0x458/0x6d0
    init_cma_reserved_pageblock+0x114/0x198
    cma_init_reserved_areas+0x270/0x3e0
    do_one_initcall+0x80/0x2f8
    kernel_init_freeable+0x33c/0x530
    kernel_init+0x34/0x26c
    ret_from_kernel_user_thread+0x14/0x1c
    
    Fixes: 11ac3e87ce09 ("mm: cma: use pageblock_order as the single alignment")
    Suggested-by: David Hildenbrand <david@redhat.com>
    Reported-by: Sachin P Bappalige <sachinpb@linux.ibm.com>
    Acked-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/3ae208e48c0d9cefe53d2dc4f593388067405b7d.1729146153.git.ritesh.list@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ffdb03366a9dfdf4b0fc2d239a04e5886a64bae
Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Date:   Fri Oct 18 21:47:55 2024 +0530

    powerpc/fadump: Refactor and prepare fadump_cma_init for late init
    
    [ Upstream commit adfaec30ffaceecd565e06adae367aa944acc3c9 ]
    
    We anyway don't use any return values from fadump_cma_init(). Since
    fadump_reserve_mem() from where fadump_cma_init() gets called today,
    already has the required checks.
    This patch makes this function return type as void. Let's also handle
    extra cases like return if fadump_supported is false or dump_active, so
    that in later patches we can call fadump_cma_init() separately from
    setup_arch().
    
    Acked-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/a2afc3d6481a87a305e89cfc4a3f3d2a0b8ceab3.1729146153.git.ritesh.list@gmail.com
    Stable-dep-of: 05b94cae1c47 ("powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd6383dd6ae01bf4bcc92ec90f6bf5f667142822
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Oct 16 17:06:15 2024 +0800

    cpufreq: loongson2: Unregister platform_driver on failure
    
    [ Upstream commit 5f856d71ccdf89b4bac0ff70ebb0bb582e7f7f18 ]
    
    When cpufreq_register_driver() returns error, the cpufreq_init() returns
    without unregister platform_driver, fix by add missing
    platform_driver_unregister() when cpufreq_register_driver() failed.
    
    Fixes: f8ede0f700f5 ("MIPS: Loongson 2F: Add CPU frequency scaling support")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ba45b8bc62e64da524d45532107ae93eb33c93c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sat Oct 5 22:27:06 2024 +0300

    mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
    
    [ Upstream commit 0350d783ab888cb1cb48ced36cc28b372723f1a4 ]
    
    While design wise the idea of converting the driver to use
    the hierarchy of the IRQ chips is correct, the implementation
    has (inherited) flaws. This was unveiled when platform_get_irq()
    had started WARN() on IRQ 0 that is supposed to be a Linux
    IRQ number (also known as vIRQ).
    
    Rework the driver to respect IRQ domain when creating each MFD
    device separately, as the domain is not the same for all of them.
    
    Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips")
    Tested-by: Zhang Ning <zhangn1985@outlook.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20241005193029.1929139-4-andriy.shevchenko@linux.intel.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56acf415772ee7e10e448b371f52b249aa2d0f7b
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sat Oct 5 22:27:05 2024 +0300

    mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
    
    [ Upstream commit 9b79d59e6b2b515eb9a22bc469ef7b8f0904fc73 ]
    
    While design wise the idea of converting the driver to use
    the hierarchy of the IRQ chips is correct, the implementation
    has (inherited) flaws. This was unveiled when platform_get_irq()
    had started WARN() on IRQ 0 that is supposed to be a Linux
    IRQ number (also known as vIRQ).
    
    Rework the driver to respect IRQ domain when creating each MFD
    device separately, as the domain is not the same for all of them.
    
    Fixes: 957ae5098185 ("platform/x86: Add Whiskey Cove PMIC TMU support")
    Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips")
    Reported-by: Zhang Ning <zhangn1985@outlook.com>
    Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com
    Tested-by: Zhang Ning <zhangn1985@outlook.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20241005193029.1929139-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c310e6916c0b297011d0fec03f168a6b24e9e984
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sat Oct 5 22:27:04 2024 +0300

    mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
    
    [ Upstream commit 686fb77712a4bc94b76a0c5ae74c60118b7a0d79 ]
    
    While design wise the idea of converting the driver to use
    the hierarchy of the IRQ chips is correct, the implementation
    has (inherited) flaws. This was unveiled when platform_get_irq()
    had started WARN() on IRQ 0 that is supposed to be a Linux
    IRQ number (also known as vIRQ).
    
    Rework the driver to respect IRQ domain when creating each MFD
    device separately, as the domain is not the same for all of them.
    
    Fixes: 9c6235c86332 ("mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device")
    Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY")
    Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips")
    Reported-by: Zhang Ning <zhangn1985@outlook.com>
    Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com
    Tested-by: Zhang Ning <zhangn1985@outlook.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20241005193029.1929139-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50952a6ff5fa399c4d8a8ec517d1e8f4e0494fb0
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Wed Sep 25 12:19:53 2024 +0200

    mfd: da9052-spi: Change read-mask to write-mask
    
    [ Upstream commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed ]
    
    Driver has mixed up the R/W bit.
    The LSB bit is set on write rather than read.
    Change it to avoid nasty things to happen.
    
    Fixes: e9e9d3973594 ("mfd: da9052: Avoid setting read_flag_mask for da9052-i2c driver")
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Link: https://lore.kernel.org/r/20240925-da9052-v2-1-f243e4505b07@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9294079187fc8e67c04374a06b0fd61728b4485
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 11:15:30 2024 +0800

    mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race
    
    [ Upstream commit 2174f9a8c9db50f74df769edd5a4ab822c73b6d2 ]
    
    As the comment said, disable_irq() after request_irq() still has a
    time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN
    flag will disable IRQ auto-enable when request IRQ.
    
    Fixes: 72cd799544f2 ("[PATCH] I2C: add i2c driver for TPS6501x")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20240912031530.2211654-1-ruanjinjie@huawei.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccfbcc7d555d7a1b91d0c1b11af692af8c3c7b40
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Oct 10 00:17:57 2024 +0200

    powerpc/vdso: Flag VDSO64 entry points as functions
    
    [ Upstream commit 0161bd38c24312853ed5ae9a425a1c41c4ac674a ]
    
    On powerpc64 as shown below by readelf, vDSO functions symbols have
    type NOTYPE.
    
    $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg
    ELF Header:
      Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
      Class:                             ELF64
      Data:                              2's complement, big endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              DYN (Shared object file)
      Machine:                           PowerPC64
      Version:                           0x1
    ...
    
    Symbol table '.dynsym' contains 12 entries:
       Num:    Value          Size Type    Bind   Vis      Ndx Name
    ...
         1: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
    ...
         4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
         5: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
    
    Symbol table '.symtab' contains 56 entries:
       Num:    Value          Size Type    Bind   Vis      Ndx Name
    ...
        45: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
        46: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __kernel_getcpu
        47: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_clock_getres
    
    To overcome that, commit ba83b3239e65 ("selftests: vDSO: fix vDSO
    symbols lookup for powerpc64") was applied to have selftests also
    look for NOTYPE symbols, but the correct fix should be to flag VDSO
    entry points as functions.
    
    The original commit that brought VDSO support into powerpc/64 has the
    following explanation:
    
        Note that the symbols exposed by the vDSO aren't "normal" function symbols, apps
        can't be expected to link against them directly, the vDSO's are both seen
        as if they were linked at 0 and the symbols just contain offsets to the
        various functions.  This is done on purpose to avoid a relocation step
        (ppc64 functions normally have descriptors with abs addresses in them).
        When glibc uses those functions, it's expected to use it's own trampolines
        that know how to reach them.
    
    The descriptors it's talking about are the OPD function descriptors
    used on ABI v1 (big endian). But it would be more correct for a text
    symbol to have type function, even if there's no function descriptor
    for it.
    
    glibc has a special case already for handling the VDSO symbols which
    creates a fake opd pointing at the kernel symbol. So changing the VDSO
    symbol type to function shouldn't affect that.
    
    For ABI v2, there is no function descriptors and VDSO functions can
    safely have function type.
    
    So lets flag VDSO entry points as functions and revert the
    selftest change.
    
    Link: https://github.com/mpe/linux-fullhistory/commit/5f2dd691b62da9d9cc54b938f8b29c22c93cb805
    Fixes: ba83b3239e65 ("selftests: vDSO: fix vDSO symbols lookup for powerpc64")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Reviewed-By: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/b6ad2f1ee9887af3ca5ecade2a56f4acda517a85.1728512263.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3887bc73d4257dd167d9c054a10e942a488a07a6
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Thu Oct 10 10:04:32 2024 +0200

    pinctrl: zynqmp: drop excess struct member description
    
    [ Upstream commit 2a85fc7044987d751f27d7f1e4423eebbcecc2c6 ]
    
    The 'node' member has never been part of this structure so drop its
    description.
    
    Fixes: 8b242ca700f8 ("pinctrl: Add Xilinx ZynqMP pinctrl driver support")
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/20241010080432.7781-1-brgl@bgdev.pl
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc344fdd0e6803e4b5bebe474bc78abab478693d
Author: Levi Yun <yeoreum.yun@arm.com>
Date:   Fri Sep 13 03:13:47 2024 +0100

    trace/trace_event_perf: remove duplicate samples on the first tracepoint event
    
    [ Upstream commit afe5960dc208fe069ddaaeb0994d857b24ac19d1 ]
    
    When a tracepoint event is created with attr.freq = 1,
    'hwc->period_left' is not initialized correctly. As a result,
    in the perf_swevent_overflow() function, when the first time the event occurs,
    it calculates the event overflow and the perf_swevent_set_period() returns 3,
    this leads to the event are recorded for three duplicate times.
    
    Step to reproduce:
        1. Enable the tracepoint event & starting tracing
             $ echo 1 > /sys/kernel/tracing/events/module/module_free
             $ echo 1 > /sys/kernel/tracing/tracing_on
    
        2. Record with perf
             $ perf record -a --strict-freq -F 1 -e "module:module_free"
    
        3. Trigger module_free event.
             $ modprobe -i sunrpc
             $ modprobe -r sunrpc
    
    Result:
         - Trace pipe result:
             $ cat trace_pipe
             modprobe-174509  [003] .....  6504.868896: module_free: sunrpc
    
         - perf sample:
             modprobe  174509 [003]  6504.868980: module:module_free: sunrpc
             modprobe  174509 [003]  6504.868980: module:module_free: sunrpc
             modprobe  174509 [003]  6504.868980: module:module_free: sunrpc
    
    By setting period_left via perf_swevent_set_period() as other sw_event did,
    This problem could be solved.
    
    After patch:
         - Trace pipe result:
             $ cat trace_pipe
             modprobe 1153096 [068] 613468.867774: module:module_free: xfs
    
         - perf sample
             modprobe 1153096 [068] 613468.867794: module:module_free: xfs
    
    Link: https://lore.kernel.org/20240913021347.595330-1-yeoreum.yun@arm.com
    Fixes: bd2b5b12849a ("perf_counter: More aggressive frequency adjustment")
    Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4387cef540f36c2c9297460758cc2438305a24a0
Author: André Almeida <andrealmeid@igalia.com>
Date:   Mon Sep 2 19:55:03 2024 -0300

    unicode: Fix utf8_load() error path
    
    [ Upstream commit 156bb2c569cd869583c593d27a5bd69e7b2a4264 ]
    
    utf8_load() requests the symbol "utf8_data_table" and then checks if the
    requested UTF-8 version is supported. If it's unsupported, it tries to
    put the data table using symbol_put(). If an unsupported version is
    requested, symbol_put() fails like this:
    
     kernel BUG at kernel/module/main.c:786!
     RIP: 0010:__symbol_put+0x93/0xb0
     Call Trace:
      <TASK>
      ? __die_body.cold+0x19/0x27
      ? die+0x2e/0x50
      ? do_trap+0xca/0x110
      ? do_error_trap+0x65/0x80
      ? __symbol_put+0x93/0xb0
      ? exc_invalid_op+0x51/0x70
      ? __symbol_put+0x93/0xb0
      ? asm_exc_invalid_op+0x1a/0x20
      ? __pfx_cmp_name+0x10/0x10
      ? __symbol_put+0x93/0xb0
      ? __symbol_put+0x62/0xb0
      utf8_load+0xf8/0x150
    
    That happens because symbol_put() expects the unique string that
    identify the symbol, instead of a pointer to the loaded symbol. Fix that
    by using such string.
    
    Fixes: 2b3d04787012 ("unicode: Add utf8-data module")
    Signed-off-by: André Almeida <andrealmeid@igalia.com>
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Link: https://lore.kernel.org/r/20240902225511.757831-2-andrealmeid@igalia.com
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 386efa339e08563dd33e83bc951aea5d407fe578
Author: Jiayuan Chen <mrpre@163.com>
Date:   Mon Nov 18 11:09:09 2024 +0800

    bpf: fix recursive lock when verdict program return SK_PASS
    
    [ Upstream commit 8ca2a1eeadf09862190b2810697702d803ceef2d ]
    
    When the stream_verdict program returns SK_PASS, it places the received skb
    into its own receive queue, but a recursive lock eventually occurs, leading
    to an operating system deadlock. This issue has been present since v6.9.
    
    '''
    sk_psock_strp_data_ready
        write_lock_bh(&sk->sk_callback_lock)
        strp_data_ready
          strp_read_sock
            read_sock -> tcp_read_sock
              strp_recv
                cb.rcv_msg -> sk_psock_strp_read
                  # now stream_verdict return SK_PASS without peer sock assign
                  __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
                  sk_psock_verdict_apply
                    sk_psock_skb_ingress_self
                      sk_psock_skb_ingress_enqueue
                        sk_psock_data_ready
                          read_lock_bh(&sk->sk_callback_lock) <= dead lock
    
    '''
    
    This topic has been discussed before, but it has not been fixed.
    Previous discussion:
    https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
    
    Fixes: 6648e613226e ("bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue")
    Reported-by: Vincent Whitchurch <vincent.whitchurch@datadoghq.com>
    Signed-off-by: Jiayuan Chen <mrpre@163.com>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://patch.msgid.link/20241118030910.36230-2-mrpre@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a628d40d2866482a17cd5029fae92db011e68e9f
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Sun Nov 17 22:20:29 2024 +0100

    wireguard: selftests: load nf_conntrack if not present
    
    [ Upstream commit 0290abc9860917f1ee8b58309c2bbd740a39ee8e ]
    
    Some distros may not load nf_conntrack by default, which will cause
    subsequent nf_conntrack sets to fail. Load this module if it is not
    already loaded.
    
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    [ Jason: add [[ -e ... ]] check so this works in the qemu harness. ]
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://patch.msgid.link/20241117212030.629159-4-Jason@zx2c4.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cd5b42796d363538e1ca808621f38b4048bb1a3
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Nov 18 03:15:18 2024 -0800

    netpoll: Use rcu_access_pointer() in netpoll_poll_lock
    
    [ Upstream commit a57d5a72f8dec7db8a79d0016fb0a3bdecc82b56 ]
    
    The ndev->npinfo pointer in netpoll_poll_lock() is RCU-protected but is
    being accessed directly for a NULL check. While no RCU read lock is held
    in this context, we should still use proper RCU primitives for
    consistency and correctness.
    
    Replace the direct NULL check with rcu_access_pointer(), which is the
    appropriate primitive when only checking for NULL without dereferencing
    the pointer. This function provides the necessary ordering guarantees
    without requiring RCU read-side protection.
    
    Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct net_device objects.")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Link: https://patch.msgid.link/20241118-netpoll_rcu-v1-2-a1888dcb4a02@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f67ca2a80acf8b207240405b7f72d660665d3df
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Fri Nov 1 14:44:10 2024 +0300

    Bluetooth: fix use-after-free in device_for_each_child()
    
    [ Upstream commit 27aabf27fd014ae037cc179c61b0bee7cff55b3d ]
    
    Syzbot has reported the following KASAN splat:
    
    BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0
    Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980
    
    CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x100/0x190
     ? device_for_each_child+0x18f/0x1a0
     print_report+0x13a/0x4cb
     ? __virt_addr_valid+0x5e/0x590
     ? __phys_addr+0xc6/0x150
     ? device_for_each_child+0x18f/0x1a0
     kasan_report+0xda/0x110
     ? device_for_each_child+0x18f/0x1a0
     ? __pfx_dev_memalloc_noio+0x10/0x10
     device_for_each_child+0x18f/0x1a0
     ? __pfx_device_for_each_child+0x10/0x10
     pm_runtime_set_memalloc_noio+0xf2/0x180
     netdev_unregister_kobject+0x1ed/0x270
     unregister_netdevice_many_notify+0x123c/0x1d80
     ? __mutex_trylock_common+0xde/0x250
     ? __pfx_unregister_netdevice_many_notify+0x10/0x10
     ? trace_contention_end+0xe6/0x140
     ? __mutex_lock+0x4e7/0x8f0
     ? __pfx_lock_acquire.part.0+0x10/0x10
     ? rcu_is_watching+0x12/0xc0
     ? unregister_netdev+0x12/0x30
     unregister_netdevice_queue+0x30d/0x3f0
     ? __pfx_unregister_netdevice_queue+0x10/0x10
     ? __pfx_down_write+0x10/0x10
     unregister_netdev+0x1c/0x30
     bnep_session+0x1fb3/0x2ab0
     ? __pfx_bnep_session+0x10/0x10
     ? __pfx_lock_release+0x10/0x10
     ? __pfx_woken_wake_function+0x10/0x10
     ? __kthread_parkme+0x132/0x200
     ? __pfx_bnep_session+0x10/0x10
     ? kthread+0x13a/0x370
     ? __pfx_bnep_session+0x10/0x10
     kthread+0x2b7/0x370
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x48/0x80
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Allocated by task 4974:
     kasan_save_stack+0x30/0x50
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0xaa/0xb0
     __kmalloc_noprof+0x1d1/0x440
     hci_alloc_dev_priv+0x1d/0x2820
     __vhci_create_device+0xef/0x7d0
     vhci_write+0x2c7/0x480
     vfs_write+0x6a0/0xfc0
     ksys_write+0x12f/0x260
     do_syscall_64+0xc7/0x250
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 4979:
     kasan_save_stack+0x30/0x50
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     __kasan_slab_free+0x4f/0x70
     kfree+0x141/0x490
     hci_release_dev+0x4d9/0x600
     bt_host_release+0x6a/0xb0
     device_release+0xa4/0x240
     kobject_put+0x1ec/0x5a0
     put_device+0x1f/0x30
     vhci_release+0x81/0xf0
     __fput+0x3f6/0xb30
     task_work_run+0x151/0x250
     do_exit+0xa79/0x2c30
     do_group_exit+0xd5/0x2a0
     get_signal+0x1fcd/0x2210
     arch_do_signal_or_restart+0x93/0x780
     syscall_exit_to_user_mode+0x140/0x290
     do_syscall_64+0xd4/0x250
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when
    an underlying (kobject) reference counter is greater than 1. This
    means that reparenting (happened when the device is actually freed)
    is delayed and, during that delay, parent controller device (hciX)
    may be deleted. Since the latter may create a dangling pointer to
    freed parent, avoid that scenario by reparenting to NULL explicitly.
    
    Reported-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com
    Tested-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=6cf5652d3df49fae2e3f
    Fixes: a85fb91e3d72 ("Bluetooth: Fix double free in hci_conn_cleanup")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea8cc56db659cf0ae57073e32a4735ead7bd7ee3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 12:10:39 2024 +0100

    ALSA: 6fire: Release resources at card release
    
    [ Upstream commit a0810c3d6dd2d29a9b92604d682eacd2902ce947 ]
    
    The current 6fire code tries to release the resources right after the
    call of usb6fire_chip_abort().  But at this moment, the card object
    might be still in use (as we're calling snd_card_free_when_closed()).
    
    For avoid potential UAFs, move the release of resources to the card's
    private_free instead of the manual call of usb6fire_chip_destroy() at
    the USB disconnect callback.
    
    Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20241113111042.15058-6-tiwai@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 237f3faf0177bdde728fa3106d730d806436aa4d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 12:10:38 2024 +0100

    ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
    
    [ Upstream commit b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c ]
    
    The USB disconnect callback is supposed to be short and not too-long
    waiting.  OTOH, the current code uses snd_card_free() at
    disconnection, but this waits for the close of all used fds, hence it
    can take long.  It eventually blocks the upper layer USB ioctls, which
    may trigger a soft lockup.
    
    An easy workaround is to replace snd_card_free() with
    snd_card_free_when_closed().  This variant returns immediately while
    the release of resources is done asynchronously by the card device
    release at the last close.
    
    This patch also splits the code to the disconnect and the free phases;
    the former is called immediately at the USB disconnect callback while
    the latter is called from the card destructor.
    
    Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20241113111042.15058-5-tiwai@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc778ad3e495333eebda36fe91d5b2c93109cc16
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 12:10:36 2024 +0100

    ALSA: us122l: Use snd_card_free_when_closed() at disconnection
    
    [ Upstream commit b7df09bb348016943f56b09dcaafe221e3f73947 ]
    
    The USB disconnect callback is supposed to be short and not too-long
    waiting.  OTOH, the current code uses snd_card_free() at
    disconnection, but this waits for the close of all used fds, hence it
    can take long.  It eventually blocks the upper layer USB ioctls, which
    may trigger a soft lockup.
    
    An easy workaround is to replace snd_card_free() with
    snd_card_free_when_closed().  This variant returns immediately while
    the release of resources is done asynchronously by the card device
    release at the last close.
    
    The loop of us122l->mmap_count check is dropped as well.  The check is
    useless for the asynchronous operation with *_when_closed().
    
    Fixes: 030a07e44129 ("ALSA: Add USB US122L driver")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20241113111042.15058-3-tiwai@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bd8838c0ea886679a32834fdcacab296d072fbe
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 13 12:10:35 2024 +0100

    ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
    
    [ Upstream commit dafb28f02be407e07a6f679e922a626592b481b0 ]
    
    The USB disconnect callback is supposed to be short and not too-long
    waiting.  OTOH, the current code uses snd_card_free() at
    disconnection, but this waits for the close of all used fds, hence it
    can take long.  It eventually blocks the upper layer USB ioctls, which
    may trigger a soft lockup.
    
    An easy workaround is to replace snd_card_free() with
    snd_card_free_when_closed().  This variant returns immediately while
    the release of resources is done asynchronously by the card device
    release at the last close.
    
    Fixes: 230cd5e24853 ("[ALSA] prevent oops & dead keyboard on usb unplugging while the device is be ing used")
    Reported-by: syzbot+73582d08864d8268b6fd@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=73582d08864d8268b6fd
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20241113111042.15058-2-tiwai@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f61b836ce94fc5642073cfa3f2e07b822a0ef641
Author: Mingwei Zheng <zmw12306@gmail.com>
Date:   Fri Nov 8 14:53:41 2024 -0500

    net: rfkill: gpio: Add check for clk_enable()
    
    [ Upstream commit 8251e7621b25ccdb689f1dd9553b8789e3745ea1 ]
    
    Add check for the return value of clk_enable() to catch the potential
    error.
    
    Fixes: 7176ba23f8b5 ("net: rfkill: add generic gpio rfkill driver")
    Signed-off-by: Mingwei Zheng <zmw12306@gmail.com>
    Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
    Link: https://patch.msgid.link/20241108195341.1853080-1-zmw12306@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c01c0b270d474c6f9d94f037eda23e6519b711cb
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Nov 6 09:35:41 2024 +0800

    drm/amdkfd: Fix wrong usage of INIT_WORK()
    
    [ Upstream commit 21cae8debc6a1d243f64fa82cd1b41cb612b5c61 ]
    
    In kfd_procfs_show(), the sdma_activity_work_handler is a local variable
    and the sdma_activity_work_handler.sdma_activity_work should initialize
    with INIT_WORK_ONSTACK() instead of INIT_WORK().
    
    Fixes: 32cb59f31362 ("drm/amdkfd: Track SDMA utilization per process")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e636d87d12e9401d43d8e5ba739940b870b2c96c
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Nov 5 19:23:51 2024 +0100

    selftests: net: really check for bg process completion
    
    [ Upstream commit 52ed077aa6336dbef83a2d6d21c52d1706fb7f16 ]
    
    A recent refactor transformed the check for process completion
    in a true statement, due to a typo.
    
    As a result, the relevant test-case is unable to catch the
    regression it was supposed to detect.
    
    Restore the correct condition.
    
    Fixes: 691bb4e49c98 ("selftests: net: avoid just another constant wait")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/0e6f213811f8e93a235307e683af8225cc6277ae.1730828007.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2f26a27ea3f72f75d18330f76f5d1007c791848
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Nov 5 19:23:50 2024 +0100

    ipv6: release nexthop on device removal
    
    [ Upstream commit eb02688c5c45c3e7af7e71f036a7144f5639cbfe ]
    
    The CI is hitting some aperiodic hangup at device removal time in the
    pmtu.sh self-test:
    
    unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6
    ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at
            dst_init+0x84/0x4a0
            dst_alloc+0x97/0x150
            ip6_dst_alloc+0x23/0x90
            ip6_rt_pcpu_alloc+0x1e6/0x520
            ip6_pol_route+0x56f/0x840
            fib6_rule_lookup+0x334/0x630
            ip6_route_output_flags+0x259/0x480
            ip6_dst_lookup_tail.constprop.0+0x5c2/0x940
            ip6_dst_lookup_flow+0x88/0x190
            udp_tunnel6_dst_lookup+0x2a7/0x4c0
            vxlan_xmit_one+0xbde/0x4a50 [vxlan]
            vxlan_xmit+0x9ad/0xf20 [vxlan]
            dev_hard_start_xmit+0x10e/0x360
            __dev_queue_xmit+0xf95/0x18c0
            arp_solicit+0x4a2/0xe00
            neigh_probe+0xaa/0xf0
    
    While the first suspect is the dst_cache, explicitly tracking the dst
    owing the last device reference via probes proved such dst is held by
    the nexthop in the originating fib6_info.
    
    Similar to commit f5b51fe804ec ("ipv6: route: purge exception on
    removal"), we need to explicitly release the originating fib info when
    disconnecting a to-be-removed device from a live ipv6 dst: move the
    fib6_info cleanup into ip6_dst_ifdown().
    
    Tested running:
    
    ./pmtu.sh cleanup_ipv6_exception
    
    in a tight loop for more than 400 iterations with no spat, running an
    unpatched kernel  I observed a splat every ~10 iterations.
    
    Fixes: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/604c45c188c609b732286b47ac2a451a40f6cf6d.1730828007.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad3c88eb3cc53f881cbbf41d584a9451c5d0e7e4
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 4 11:16:03 2024 +0000

    net: use unrcu_pointer() helper
    
    [ Upstream commit b4cb4a1391dcdc640c4ade003aaf0ee19cc8d509 ]
    
    Toke mentioned unrcu_pointer() existence, allowing
    to remove some of the ugly casts we have when using
    xchg() for rcu protected pointers.
    
    Also make inet_rcv_compat const.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Toke Høiland-Jørgensen <toke@redhat.com>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/r/20240604111603.45871-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adf86509384a70a4780bc94eee43f15e8d36ce01
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 22 11:26:01 2024 +0000

    sock_diag: allow concurrent operation in sock_diag_rcv_msg()
    
    [ Upstream commit 86e8921df05c6e9423ab74ab8d41022775d8b83a ]
    
    TCPDIAG_GETSOCK and DCCPDIAG_GETSOCK diag are serialized
    on sock_diag_table_mutex.
    
    This is to make sure inet_diag module is not unloaded
    while diag was ongoing.
    
    It is time to get rid of this mutex and use RCU protection,
    allowing full parallelism.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 916551244aeed179c4613091edc2a8e4539b83e9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 22 11:26:00 2024 +0000

    sock_diag: allow concurrent operations
    
    [ Upstream commit 1d55a6974756cf3979efd2cc68bcece611a44053 ]
    
    sock_diag_broadcast_destroy_work() and __sock_diag_cmd()
    are currently using sock_diag_table_mutex to protect
    against concurrent sock_diag_handlers[] changes.
    
    This makes inet_diag dump serialized, thus less scalable
    than legacy /proc files.
    
    It is time to switch to full RCU protection.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c116890ae8b71e4f8e8639a8ca3c01a8c4becc8
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 22 11:25:59 2024 +0000

    sock_diag: add module pointer to "struct sock_diag_handler"
    
    [ Upstream commit 114b4bb1cc19239b272d52ebbe156053483fe2f8 ]
    
    Following patch is going to use RCU instead of
    sock_diag_table_mutex acquisition.
    
    This patch is a preparation, no change of behavior yet.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9610b690335c891e4a6b1e04b39f6594addd6e09
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:20 2024 +0000

    bpf, sockmap: Fix sk_msg_reset_curr
    
    [ Upstream commit 955afd57dc4bf7e8c620a0a9e3af3c881c2c6dff ]
    
    Found in the test_txmsg_pull in test_sockmap,
    ```
    txmsg_cork = 512; // corking is importrant here
    opt->iov_length = 3;
    opt->iov_count = 1;
    opt->rate = 512; // sendmsg will be invoked 512 times
    ```
    The first sendmsg will send an sk_msg with size 3, and bpf_msg_pull_data
    will be invoked the first time. sk_msg_reset_curr will reset the copybreak
    from 3 to 0. In the second sendmsg, since we are in the stage of corking,
    psock->cork will be reused in func sk_msg_alloc. msg->sg.copybreak is 0
    now, the second msg will overwrite the first msg. As a result, we could
    not pass the data integrity test.
    
    The same problem happens in push and pop test. Thus, fix sk_msg_reset_curr
    to restore the correct copybreak.
    
    Fixes: bb9aefde5bba ("bpf: sockmap, updating the sg structure should also update curr")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-9-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f58d3aa457e77a3d9b3df2ab081dcf9950f6029f
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:19 2024 +0000

    bpf, sockmap: Several fixes to bpf_msg_pop_data
    
    [ Upstream commit 5d609ba262475db450ba69b8e8a557bd768ac07a ]
    
    Several fixes to bpf_msg_pop_data,
    1. In sk_msg_shift_left, we should put_page
    2. if (len == 0), return early is better
    3. pop the entire sk_msg (last == msg->sg.size) should be supported
    4. Fix for the value of variable "a"
    5. In sk_msg_shift_left, after shifting, i has already pointed to the next
    element. Addtional sk_msg_iter_var_next may result in BUG.
    
    Fixes: 7246d8ed4dcc ("bpf: helper to pop data from messages")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-8-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cadfa4d23f52b0f13e702ad08de92014756fba55
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:18 2024 +0000

    bpf, sockmap: Several fixes to bpf_msg_push_data
    
    [ Upstream commit 15ab0548e3107665c34579ae523b2b6e7c22082a ]
    
    Several fixes to bpf_msg_push_data,
    1. test_sockmap has tests where bpf_msg_push_data is invoked to push some
    data at the end of a message, but -EINVAL is returned. In this case, in
    bpf_msg_push_data, after the first loop, i will be set to msg->sg.end, add
    the logic to handle it.
    2. In the code block of "if (start - offset)", it's possible that "i"
    points to the last of sk_msg_elem. In this case, "sk_msg_iter_next(msg,
    end)" might still be called twice, another invoking is in "if (!copy)"
    code block, but actually only one is needed. Add the logic to handle it,
    and reconstruct the code to make the logic more clear.
    
    Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-7-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f5d3dd1421066e419021f1b5c3a60da0fa9c0a2
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:16 2024 +0000

    selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap
    
    [ Upstream commit 862087c3d36219ed44569666eb263efc97f00c9a ]
    
    Add push/pop checking for msg_verify_data in test_sockmap, except for
    pop/push with cork tests, in these tests the logic will be different.
    1. With corking, pop/push might not be invoked in each sendmsg, it makes
    the layout of the received data difficult
    2. It makes it hard to calculate the total_bytes in the recvmsg
    Temporarily skip the data integrity test for these cases now, added a TODO
    
    Fixes: ee9b352ce465 ("selftests/bpf: Fix msg_verify_data in test_sockmap")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-5-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a9eebcee47cc3e0232d8d2c696b260e84eef3f6
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:15 2024 +0000

    selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap
    
    [ Upstream commit 523dffccbadea0cfd65f1ff04944b864c558c4a8 ]
    
    total_bytes in msg_loop_rx should also take push into account, otherwise
    total_bytes will be a smaller value, which makes the msg_loop_rx end early.
    
    Besides, total_bytes has already taken pop into account, so we don't need
    to subtract some bytes from iov_buf in sendmsg_test. The additional
    subtraction may make total_bytes a negative number, and msg_loop_rx will
    just end without checking anything.
    
    Fixes: 18d4e900a450 ("bpf: Selftests, improve test_sockmap total bytes counter")
    Fixes: d69672147faa ("selftests, bpf: Add one test for sockmap with strparser")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-4-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bff469c83123e9c1861d14d17194fbb34d1c772
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:14 2024 +0000

    selftests/bpf: Fix SENDPAGE data logic in test_sockmap
    
    [ Upstream commit 4095031463d4e99b534d2cd82035a417295764ae ]
    
    In the SENDPAGE test, "opt->iov_length * cnt" size of data will be sent
    cnt times by sendfile.
    1. In push/pop tests, they will be invoked cnt times, for the simplicity of
    msg_verify_data, change chunk_sz to iov_length
    2. Change iov_length in test_send_large from 1024 to 8192. We have pop test
    where txmsg_start_pop is 4096. 4096 > 1024, an error will be returned.
    
    Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-3-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a479d22242cf2efc4c00a6c1d7197e4cbbf3b559
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Wed Nov 6 22:25:13 2024 +0000

    selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap
    
    [ Upstream commit 66c54c20408d994be34be2c070fba08472f69eee ]
    
    Add txmsg_pass to test_txmsg_pull/push/pop. If txmsg_pass is missing,
    tx_prog will be NULL, and no program will be attached to the sockmap.
    As a result, pull/push/pop are never invoked.
    
    Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests")
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20241106222520.527076-2-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f500518cc89d51fc1f29dc11784ce1b91ba78c0e
Author: Maurice Lambert <mauricelambert434@gmail.com>
Date:   Sun Nov 3 23:39:50 2024 +0100

    netlink: typographical error in nlmsg_type constants definition
    
    [ Upstream commit 84bfbfbbd32aee136afea4b6bf82581dce79c305 ]
    
    This commit fix a typographical error in netlink nlmsg_type constants definition in the include/uapi/linux/rtnetlink.h at line 177. The definition is RTM_NEWNVLAN RTM_NEWVLAN instead of RTM_NEWVLAN RTM_NEWVLAN.
    
    Signed-off-by: Maurice Lambert <mauricelambert434@gmail.com>
    Fixes: 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump support")
    Link: https://patch.msgid.link/20241103223950.230300-1-mauricelambert434@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c49d377079048f4d94e49dfdb67cea00100e4ef
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Nov 4 10:41:19 2024 +0100

    netfilter: nf_tables: must hold rcu read lock while iterating object type list
    
    [ Upstream commit cddc04275f95ca3b18da5c0fb111705ac173af89 ]
    
    Update of stateful object triggers:
    WARNING: suspicious RCU usage
    net/netfilter/nf_tables_api.c:7759 RCU-list traversed in non-reader section!!
    
    other info that might help us debug this:
    rcu_scheduler_active = 2, debug_locks = 1
    1 lock held by nft/3060:
     #0: ffff88810f0578c8 (&nft_net->commit_mutex){+.+.}-{4:4}, [..]
    
    ... but this list is not protected by the transaction mutex but the
    nfnl nftables subsystem mutex.
    
    Switch to nft_obj_type_get which will acquire rcu read lock,
    bump refcount, and returns the result.
    
    v3: Dan Carpenter points out nft_obj_type_get returns error pointer, not
    NULL, on error.
    
    Fixes: dad3bdeef45f ("netfilter: nf_tables: fix memory leak during stateful obj update").
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7703551d0b2dbd53a865e00468c1488578335125
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Mar 5 09:35:48 2024 +0100

    netfilter: nf_tables: skip transaction if update object is not implemented
    
    [ Upstream commit 84b1a0c0140a9a92ea108576c0002210f224ce59 ]
    
    Turn update into noop as a follow up for:
    
      9fedd894b4e1 ("netfilter: nf_tables: fix unexpected EOPNOTSUPP error")
    
    instead of adding a transaction object which is simply discarded at a
    later stage of the commit protocol.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: cddc04275f95 ("netfilter: nf_tables: must hold rcu read lock while iterating object type list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f6f583be369aed4a848f4dc9241490d1caedfb3
Author: Zichen Xie <zichenxie0106@gmail.com>
Date:   Tue Oct 29 14:42:10 2024 -0500

    drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()
    
    [ Upstream commit 20c7b42d9dbd048019bfe0af39229e3014007a98 ]
    
    There may be a potential integer overflow issue in
    _dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while
    mode->vtotal, mode->hdisplay, and drm_mode_vrefresh(mode) are defined as
    a smaller data type. The result of the calculation will be limited to
    "int" in this case without correct casting. In screen with high
    resolution and high refresh rate, integer overflow may happen.
    So, we recommend adding an extra cast to prevent potential
    integer overflow.
    
    Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
    Signed-off-by: Zichen Xie <zichenxie0106@gmail.com>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/622206/
    Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27591e2e9116415c9ae9fe7d5d6fa55d25cfc890
Author: Yuan Can <yuancan@huawei.com>
Date:   Tue Oct 22 17:04:53 2024 +0800

    wifi: wfx: Fix error handling in wfx_core_init()
    
    [ Upstream commit 3b88a9876779b55478a4dde867e73f7a100ffa23 ]
    
    The wfx_core_init() returns without checking the retval from
    sdio_register_driver().
    If the sdio_register_driver() failed, the module failed to install,
    leaving the wfx_spi_driver not unregistered.
    
    Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a8c948d3a5854f1818ae36814966d2f0e6b4db5
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Jul 5 22:00:09 2024 +0200

    drm/etnaviv: hold GPU lock across perfmon sampling
    
    [ Upstream commit 37dc4737447a7667f8e9ec790dac251da057eb27 ]
    
    The perfmon sampling mutates shared GPU state (e.g. VIVS_HI_CLOCK_CONTROL
    to select the pipe for the perf counter reads). To avoid clashing with
    other functions mutating the same state (e.g. etnaviv_gpu_update_clock)
    the perfmon sampling needs to hold the GPU lock.
    
    Fixes: 68dc0b295dcb ("drm/etnaviv: use 'sync points' for performance monitor requests")
    Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8cae8a21b2893370127516800f6f1c5f0e8db38
Author: Doug Brown <doug@schmorgal.com>
Date:   Sat Sep 10 13:29:39 2022 -0700

    drm/etnaviv: fix power register offset on GC300
    
    [ Upstream commit 61a6920bb604df3a0e389a2a9479e1e233e4461d ]
    
    Older GC300 revisions have their power registers at an offset of 0x200
    rather than 0x100. Add new gpu_read_power and gpu_write_power functions
    to encapsulate accesses to the power addresses and fix the addresses.
    
    Signed-off-by: Doug Brown <doug@schmorgal.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Stable-dep-of: 37dc4737447a ("drm/etnaviv: hold GPU lock across perfmon sampling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab96894ade42b2e128f2a20cbffef5f1537f4526
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Wed Oct 2 07:34:30 2024 +0800

    drm/etnaviv: Request pages from DMA32 zone on addressing_limited
    
    [ Upstream commit 13c96ac9a3f0f1c7ba1ff0656ea508e7fa065e7e ]
    
    Remove __GFP_HIGHMEM when requesting a page from DMA32 zone,
    and since all vivante GPUs in the system will share the same
    DMA constraints, move the check of whether to get a page from
    DMA32 to etnaviv_bind().
    
    Fixes: b72af445cd38 ("drm/etnaviv: request pages from DMA32 zone when needed")
    Suggested-by: Sui Jingfeng <sui.jingfeng@linux.dev>
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1867879b7a47bddaac5db3a140aeb1e338adeb1e
Author: Lukasz Luba <lukasz.luba@arm.com>
Date:   Fri Oct 18 12:18:11 2024 +0100

    drm/msm/gpu: Check the status of registration to PM QoS
    
    [ Upstream commit 8f32ddd87e499ba6d2dc74ce30b6932baf1e1fc3 ]
    
    There is a need to check the returned value of the registration function.
    In case of returned error, print that and stop the init process.
    
    Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints")
    Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
    Patchwork: https://patchwork.freedesktop.org/patch/620336/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 372f00e22e06e3bf91b25a69cb4bdd312c46add1
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Jan 10 15:14:43 2023 -0800

    drm/msm/gpu: Bypass PM QoS constraint for idle clamp
    
    [ Upstream commit fadcc3ab1302d4e5baa32c272b658221f0066696 ]
    
    Change idle freq clamping back to the direct method, bypassing PM QoS
    requests.  The problem with using PM QoS requests is they call
    (indirectly) the governors ->get_target_freq() which goes thru a
    get_dev_status() cycle.  The problem comes when the GPU becomes active
    again and we remove the idle-clamp request, we go through another
    get_dev_status() cycle for the period that the GPU has been idle, which
    triggers the governor to lower the target freq excessively.
    
    This partially reverts commit 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS
    constraints"), but preserves the use of boost QoS request, so that it
    will continue to play nicely with other QoS requests such as a cooling
    device.  This also mostly undoes commit 78f815c1cf8f ("drm/msm: return the
    average load over the polling period")
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/517785/
    Link: https://lore.kernel.org/r/20230110231447.1939101-3-robdclark@gmail.com
    Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
    Stable-dep-of: 8f32ddd87e49 ("drm/msm/gpu: Check the status of registration to PM QoS")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d187dcbaa037bd61f3accc5e3a1a315ac937744
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Jan 10 15:14:42 2023 -0800

    drm/msm/gpu: Add devfreq tuning debugfs
    
    [ Upstream commit 6563f60f14cbb3dcbdc4e1d8469fc0fbaaa80544 ]
    
    Make the handful of tuning knobs available visible via debugfs.
    
    v2: select DEVFREQ_GOV_SIMPLE_ONDEMAND because for some reason
        struct devfreq_simple_ondemand_data depends on this
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/517784/
    Link: https://lore.kernel.org/r/20230110231447.1939101-2-robdclark@gmail.com
    Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
    Stable-dep-of: 8f32ddd87e49 ("drm/msm/gpu: Check the status of registration to PM QoS")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e57e58ecf48cc2a0c431cde434716c12ad550a2
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 16:30:20 2024 +0800

    drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 394679f322649d06fea3c646ba65f5a0887f52c3 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Patchwork: https://patchwork.freedesktop.org/patch/614075/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e63fd47e6279df9b91048acafdee21126d8c6fc
Author: Xu Kuohai <xukuohai@huawei.com>
Date:   Fri Oct 25 16:52:20 2024 +0800

    bpf, arm64: Remove garbage frame for struct_ops trampoline
    
    [ Upstream commit 87cb58aebdf7005661a07e9fd5a900f924d48c75 ]
    
    The callsite layout for arm64 fentry is:
    
    mov x9, lr
    nop
    
    When a bpf prog is attached, the nop instruction is patched to a call
    to bpf trampoline:
    
    mov x9, lr
    bl <bpf trampoline>
    
    So two return addresses are passed to bpf trampoline: the return address
    for the traced function/prog, stored in x9, and the return address for
    the bpf trampoline itself, stored in lr. To obtain a full and accurate
    call stack, the bpf trampoline constructs two fake function frames using
    x9 and lr.
    
    However, struct_ops progs are invoked directly as function callbacks,
    meaning that x9 is not set as it is in the fentry callsite. In this case,
    the frame constructed using x9 is garbage. The following stack trace for
    struct_ops, captured by perf sampling, illustrates this issue, where
    tcp_ack+0x404 is a garbage frame:
    
    ffffffc0801a04b4 bpf_prog_50992e55a0f655a9_bpf_cubic_cong_avoid+0x98 (bpf_prog_50992e55a0f655a9_bpf_cubic_cong_avoid)
    ffffffc0801a228c [unknown] ([kernel.kallsyms]) // bpf trampoline
    ffffffd08d362590 tcp_ack+0x798 ([kernel.kallsyms]) // caller for bpf trampoline
    ffffffd08d3621fc tcp_ack+0x404 ([kernel.kallsyms]) // garbage frame
    ffffffd08d36452c tcp_rcv_established+0x4ac ([kernel.kallsyms])
    ffffffd08d375c58 tcp_v4_do_rcv+0x1f0 ([kernel.kallsyms])
    ffffffd08d378630 tcp_v4_rcv+0xeb8 ([kernel.kallsyms])
    
    To fix it, construct only one frame using lr for struct_ops.
    
    The above stack trace also indicates that there is no kernel symbol for
    struct_ops bpf trampoline. This will be addressed in a follow-up patch.
    
    Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64")
    Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
    Acked-by: Puranjay Mohan <puranjay@kernel.org>
    Tested-by: Puranjay Mohan <puranjay@kernel.org>
    Link: https://lore.kernel.org/r/20241025085220.533949-1-xukuohai@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f544cfc96c76893e95ec81992566a9bc514c400
Author: Steven Price <steven.price@arm.com>
Date:   Fri Oct 25 15:00:07 2024 +0100

    drm/panfrost: Remove unused id_mask from struct panfrost_model
    
    [ Upstream commit 581d1f8248550f2b67847e6d84f29fbe3751ea0a ]
    
    The id_mask field of struct panfrost_model has never been used.
    
    Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
    Signed-off-by: Steven Price <steven.price@arm.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20241025140008.385081-1-steven.price@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b94052830e3cd3be7141789a5ce6e62cf9f620a4
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 19:16:16 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c
    
    [ Upstream commit 69297b0d3369488af259e3a7cf53d69157938ea1 ]
    
    Add error pointer check after calling otx2_mbox_get_rsp().
    
    Fixes: 8e67558177f8 ("octeontx2-pf: PFC config support with DCBx")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1611b1ea7cf8d07dff091a45389b10401bb6d5b3
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 19:13:54 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c
    
    [ Upstream commit f5b942e6c54b13246ee49d42dcfb71b7f29e3c64 ]
    
    Add error pointer checks after calling otx2_mbox_get_rsp().
    
    Fixes: 79d2be385e9e ("octeontx2-pf: offload DMAC filters to CGX/RPM block")
    Fixes: fa5e0ccb8f3a ("octeontx2-pf: Add support for exact match table.")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 856ad633e11869729be698df2287ecfe6ec31f27
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 19:10:36 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c
    
    [ Upstream commit ac9183023b6a9c09467516abd8aab04f9a2f9564 ]
    
    Add error pointer check after calling otx2_mbox_get_rsp().
    
    Fixes: 2ca89a2c3752 ("octeontx2-pf: TC_MATCHALL ingress ratelimiting offload")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c9f8b35dc3d4ad8053a72bc0c5a7843591f6b75
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 19:08:44 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c
    
    [ Upstream commit bd3110bc102ab6292656b8118be819faa0de8dd0 ]
    
    Adding error pointer check after calling otx2_mbox_get_rsp().
    
    Fixes: 9917060fc30a ("octeontx2-pf: Cleanup flow rule management")
    Fixes: f0a1913f8a6f ("octeontx2-pf: Add support for ethtool ntuple filters")
    Fixes: 674b3e164238 ("octeontx2-pf: Add additional checks while configuring ucast/bcast/mcast rules")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05a6ce174c0c724e5914e1e5efd826bab8f382b4
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 19:02:29 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
    
    [ Upstream commit e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c ]
    
    Add error pointer check after calling otx2_mbox_get_rsp().
    
    Fixes: 75f36270990c ("octeontx2-pf: Support to enable/disable pause frames via ethtool")
    Fixes: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9265b6ee754226f61bd122ec57141a781d4e0dcb
Author: Dipendra Khadka <kdipendra88@gmail.com>
Date:   Thu Oct 17 18:56:33 2024 +0000

    octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c
    
    [ Upstream commit 0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 ]
    
    Add error pointer check after calling otx2_mbox_get_rsp().
    
    Fixes: ab58a416c93f ("octeontx2-pf: cn10k: Get max mtu supported from admin function")
    Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bea5fa60162c9f63ad99820658f8fd10f7727aa
Author: Matthias Schiffer <matthias.schiffer@tq-group.com>
Date:   Thu Sep 26 07:55:51 2024 +0200

    drm: fsl-dcu: enable PIXCLK on LS1021A
    
    [ Upstream commit ffcde9e44d3e18fde3d18bfff8d9318935413bfd ]
    
    The PIXCLK needs to be enabled in SCFG before accessing certain DCU
    registers, or the access will hang. For simplicity, the PIXCLK is enabled
    unconditionally, resulting in increased power consumption.
    
    Signed-off-by: Matthias Schiffer <matthias.schiffer@tq-group.com>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Fixes: 109eee2f2a18 ("drm/layerscape: Add Freescale DCU DRM driver")
    Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240926055552.1632448-2-alexander.stein@ew.tq-group.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b466746cfb6be43f9a1457bbee52ade397fb23ea
Author: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Date:   Tue Oct 8 01:20:54 2024 +0300

    wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
    
    [ Upstream commit d241a139c2e9f8a479f25c75ebd5391e6a448500 ]
    
    Replace one-element array with a flexible-array member in `struct
    mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
    on a MT8173 Chromebook (mt8173-elm-hana):
    
    [  356.775250] ------------[ cut here ]------------
    [  356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
    [  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
    
    The "(size 6)" above is exactly the length of the SSID of the network
    this device was connected to. The source of the warning looks like:
    
        ssid_len = user_scan_in->ssid_list[i].ssid_len;
        [...]
        memcpy(wildcard_ssid_tlv->ssid,
               user_scan_in->ssid_list[i].ssid, ssid_len);
    
    There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
    struct, but it already didn't account for the size of the one-element
    array, so it doesn't need to be changed.
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 861cebee260a6e4efcb4ca9be14af350b9c37c81
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Sat Oct 12 20:37:31 2024 +0000

    selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap
    
    [ Upstream commit b29e231d66303c12b7b8ac3ac2a057df06b161e8 ]
    
    txmsg_redir in "Test pull + redirect" case of test_txmsg_pull should be
    1 instead of 0.
    
    Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests")
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Link: https://lore.kernel.org/r/20241012203731.1248619-3-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a315b5b672bf3efe3b217fc8cd220b156bf0aafc
Author: Zijian Zhang <zijianzhang@bytedance.com>
Date:   Sat Oct 12 20:37:30 2024 +0000

    selftests/bpf: Fix msg_verify_data in test_sockmap
    
    [ Upstream commit ee9b352ce4650ffc0d8ca0ac373d7c009c7e561e ]
    
    Function msg_verify_data should have context of bytes_cnt and k instead of
    assuming they are zero. Otherwise, test_sockmap with data integrity test
    will report some errors. I also fix the logic related to size and index j
    
    1/ 6  sockmap::txmsg test passthrough:FAIL
    2/ 6  sockmap::txmsg test redirect:FAIL
    7/12  sockmap::txmsg test apply:FAIL
    10/11  sockmap::txmsg test push_data:FAIL
    11/17  sockmap::txmsg test pull-data:FAIL
    12/ 9  sockmap::txmsg test pop-data:FAIL
    13/ 1  sockmap::txmsg test push/pop data:FAIL
    ...
    Pass: 24 Fail: 52
    
    After applying this patch, some of the errors are solved, but for push,
    pull and pop, we may need more fixes to msg_verify_data, added a TODO
    
    10/11  sockmap::txmsg test push_data:FAIL
    11/17  sockmap::txmsg test pull-data:FAIL
    12/ 9  sockmap::txmsg test pop-data:FAIL
    ...
    Pass: 37 Fail: 15
    
    Besides, added a custom errno EDATAINTEGRITY for msg_verify_data, we
    shall not ignore the error in txmsg_cork case.
    
    Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap")
    Fixes: 16edddfe3c5d ("selftests/bpf: test_sockmap, check test failure")
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
    Link: https://lore.kernel.org/r/20241012203731.1248619-2-zijianzhang@bytedance.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df3554b221507fc100fec8a5486dd7e606678a65
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Nov 8 13:27:23 2023 +0200

    drm/bridge: tc358767: Fix link properties discovery
    
    [ Upstream commit 2d343723c7e1f9f6d64f721f07cfdfc2993758d1 ]
    
    When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR,
    tc358767 will behave properly and skip the creation of the connector.
    
    However, tc_get_display_props(), which is used to find out about the DP
    monitor and link, is only called from two places: .atomic_enable() and
    tc_connector_get_modes(). The latter is only used when tc358767 creates
    its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_
    set.
    
    Thus, the driver never finds out the link properties before get_edid()
    is called. With num_lanes of 0 and link_rate of 0 there are not many
    valid modes...
    
    Fix this by adding tc_get_display_props() call at the beginning of
    get_edid(), so that we have up to date information before looking at the
    modes.
    
    Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
    Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/
    Fixes: de5e6c027ae6 ("drm/bridge: tc358767: add drm_panel_bridge support")
    Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231108-tc358767-v2-2-25c5f70a2159@ideasonboard.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3a9001123797ad5e100aa66ff720d085bb12890
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Oct 10 04:00:26 2024 +0000

    netdevsim: copy addresses for both in and out paths
    
    [ Upstream commit 2cf567f421dbfe7e53b7e5ddee9400da10efb75d ]
    
    The current code only copies the address for the in path, leaving the out
    path address set to 0. This patch corrects the issue by copying the addresses
    for both the in and out paths. Before this patch:
    
      # cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec
      SA count=2 tx=20
      sa[0] tx ipaddr=0.0.0.0
      sa[0]    spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1
      sa[0]    key=0x3167608a ca4f1397 43565909 941fa627
      sa[1] rx ipaddr=192.168.0.1
      sa[1]    spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1
      sa[1]    key=0x3167608a ca4f1397 43565909 941fa627
    
    After this patch:
    
      = cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec
      SA count=2 tx=20
      sa[0] tx ipaddr=192.168.0.2
      sa[0]    spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1
      sa[0]    key=0x3167608a ca4f1397 43565909 941fa627
      sa[1] rx ipaddr=192.168.0.1
      sa[1]    spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1
      sa[1]    key=0x3167608a ca4f1397 43565909 941fa627
    
    Fixes: 7699353da875 ("netdevsim: add ipsec offload testing")
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://patch.msgid.link/20241010040027.21440-3-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 241aef4f88e35234b2f7d27ffb34ce296389b38b
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Oct 10 14:17:30 2024 -0700

    libbpf: never interpret subprogs in .text as entry programs
    
    [ Upstream commit db089c9158c1d535a36dfc010e5db37fccea2561 ]
    
    Libbpf pre-1.0 had a legacy logic of allowing singular non-annotated
    (i.e., not having explicit SEC() annotation) function to be treated as
    sole entry BPF program (unless there were other explicit entry
    programs).
    
    This behavior was dropped during libbpf 1.0 transition period (unless
    LIBBPF_STRICT_SEC_NAME flag was unset in libbpf_mode). When 1.0 was
    released and all the legacy behavior was removed, the bug slipped
    through leaving this legacy behavior around.
    
    Fix this for good, as it actually causes very confusing behavior if BPF
    object file only has subprograms, but no entry programs.
    
    Fixes: bd054102a8c7 ("libbpf: enforce strict libbpf 1.0 behaviors")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20241010211731.4121837-1-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da508bb398ebfaf6cda4378cb9cc412a2657727b
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Tue Oct 8 18:15:54 2024 -0700

    libbpf: fix sym_is_subprog() logic for weak global subprogs
    
    [ Upstream commit 4073213488be542f563eb4b2457ab4cbcfc2b738 ]
    
    sym_is_subprog() is incorrectly rejecting relocations against *weak*
    global subprogs. Fix that by realizing that STB_WEAK is also a global
    function.
    
    While it seems like verifier doesn't support taking an address of
    non-static subprog right now, it's still best to fix support for it on
    libbpf side, otherwise users will get a very confusing error during BPF
    skeleton generation or static linking due to misinterpreted relocation:
    
      libbpf: prog 'handle_tp': bad map relo against 'foo' in section '.text'
      Error: failed to open BPF object file: Relocation failed
    
    It's clearly not a map relocation, but is treated and reported as such
    without this fix.
    
    Fixes: 53eddb5e04ac ("libbpf: Support subprog address relocation")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20241009011554.880168-1-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b15f3d26c4d7221dfd7984e5efa3d568a5f6b923
Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Date:   Tue Oct 8 16:50:57 2024 +0200

    selftests/bpf: add missing header include for htons
    
    [ Upstream commit bc9b3fb827fceec4e05564d6e668280f4470ab5b ]
    
    Including the network_helpers.h header in tests can lead to the following
    build error:
    
    ./network_helpers.h: In function ‘csum_tcpudp_magic’:
    ./network_helpers.h:116:14: error: implicit declaration of function \
      ‘htons’ [-Werror=implicit-function-declaration]
      116 |         s += htons(proto + len);
    
    The error is avoided in many cases thanks to some other headers included
    earlier and bringing in arpa/inet.h (ie: test_progs.h).
    
    Make sure that test_progs build success does not depend on header ordering
    by adding the missing header include in network_helpers.h
    
    Fixes: f6642de0c3e9 ("selftests/bpf: Add csum helpers")
    Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
    Link: https://lore.kernel.org/r/20241008-network_helpers_fix-v1-1-2c2ae03df7ef@bootlin.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2eda63873b4c3975dc5316dab15c11a4c1558c8d
Author: Eduard Zingerman <eddyz87@gmail.com>
Date:   Thu Oct 3 14:03:07 2024 -0700

    selftests/bpf: Fix backtrace printing for selftests crashes
    
    [ Upstream commit 5bf1557e3d6a69113649d831276ea2f97585fc33 ]
    
    test_progs uses glibc specific functions backtrace() and
    backtrace_symbols_fd() to print backtrace in case of SIGSEGV.
    
    Recent commit (see fixes) updated test_progs.c to define stub versions
    of the same functions with attriubte "weak" in order to allow linking
    test_progs against musl libc. Unfortunately this broke the backtrace
    handling for glibc builds.
    
    As it turns out, glibc defines backtrace() and backtrace_symbols_fd()
    as weak:
    
      $ llvm-readelf --symbols /lib64/libc.so.6 \
         | grep -P '( backtrace_symbols_fd| backtrace)$'
      4910: 0000000000126b40   161 FUNC    WEAK   DEFAULT    16 backtrace
      6843: 0000000000126f90   852 FUNC    WEAK   DEFAULT    16 backtrace_symbols_fd
    
    So does test_progs:
    
     $ llvm-readelf --symbols test_progs \
        | grep -P '( backtrace_symbols_fd| backtrace)$'
      2891: 00000000006ad190    15 FUNC    WEAK   DEFAULT    13 backtrace
     11215: 00000000006ad1a0    41 FUNC    WEAK   DEFAULT    13 backtrace_symbols_fd
    
    In such situation dynamic linker is not obliged to favour glibc
    implementation over the one defined in test_progs.
    
    Compiling with the following simple modification to test_progs.c
    demonstrates the issue:
    
      $ git diff
      ...
      \--- a/tools/testing/selftests/bpf/test_progs.c
      \+++ b/tools/testing/selftests/bpf/test_progs.c
      \@@ -1817,6 +1817,7 @@ int main(int argc, char **argv)
              if (err)
                      return err;
    
      +       *(int *)0xdeadbeef  = 42;
              err = cd_flavor_subdir(argv[0]);
              if (err)
                      return err;
    
      $ ./test_progs
      [0]: Caught signal #11!
      Stack trace:
      <backtrace not supported>
      Segmentation fault (core dumped)
    
    Resolve this by hiding stub definitions behind __GLIBC__ macro check
    instead of using "weak" attribute.
    
    Fixes: c9a83e76b5a9 ("selftests/bpf: Fix compile if backtrace support missing in libc")
    Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Tony Ambardar <tony.ambardar@gmail.com>
    Reviewed-by: Tony Ambardar <tony.ambardar@gmail.com>
    Acked-by: Daniel Xu <dxu@dxuuu.xyz>
    Link: https://lore.kernel.org/bpf/20241003210307.3847907-1-eddyz87@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a75c14af69a18729a0401ec3ece8b0163b91189
Author: Stanislav Fomichev <sdf@fomichev.me>
Date:   Mon Nov 27 11:03:16 2023 -0800

    selftests/bpf: Add csum helpers
    
    [ Upstream commit f6642de0c3e94d3ef6f44e127d11fcf4138873f7 ]
    
    Checksum helpers will be used to calculate pseudo-header checksum in
    AF_XDP metadata selftests.
    
    The helpers are mirroring existing kernel ones:
    - csum_tcpudp_magic : IPv4 pseudo header csum
    - csum_ipv6_magic : IPv6 pseudo header csum
    - csum_fold : fold csum and do one's complement
    
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20231127190319.1190813-11-sdf@google.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Stable-dep-of: 5bf1557e3d6a ("selftests/bpf: Fix backtrace printing for selftests crashes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79c83dc3c819f23fe37ee0429a367b0bb32f59fd
Author: Yuan Chen <chenyuan@kylinos.cn>
Date:   Mon Sep 30 10:41:15 2024 +0800

    bpf: Fix the xdp_adjust_tail sample prog issue
    
    [ Upstream commit 4236f114a3ffbbfd217436c08852e94cae372f57 ]
    
    During the xdp_adjust_tail test, probabilistic failure occurs and SKB package
    is discarded by the kernel. After checking the issues by tracking SKB package,
    it is identified that they were caused by checksum errors. Refer to checksum
    of the arch/arm64/include/asm/checksum.h for fixing.
    
    v2: Based on Alexei Starovoitov's suggestions, it is necessary to keep the code
     implementation consistent.
    
    Fixes: c6ffd1ff7856 (bpf: add bpf_xdp_adjust_tail sample prog)
    Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240930024115.52841-1-chenyuan_fl@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d0307b1aa0d3f68e289eb2ca93a4ff3a941b81f7
Author: Tony Ambardar <tony.ambardar@gmail.com>
Date:   Mon Sep 16 01:37:42 2024 -0700

    libbpf: Fix output .symtab byte-order during linking
    
    [ Upstream commit f896b4a5399e97af0b451fcf04754ed316935674 ]
    
    Object linking output data uses the default ELF_T_BYTE type for '.symtab'
    section data, which disables any libelf-based translation. Explicitly set
    the ELF_T_SYM type for output to restore libelf's byte-order conversion,
    noting that input '.symtab' data is already correctly translated.
    
    Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs")
    Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/87868bfeccf3f51aec61260073f8778e9077050a.1726475448.git.tony.ambardar@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f3288f2bd5e3847553ac09febc9fcb0e97a444b
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Thu Sep 26 17:29:08 2024 +0800

    drm/bridge: anx7625: Drop EDID cache on bridge power off
    
    [ Upstream commit 00ae002116a14c2e6a342c4c9ae080cdbb9b4b21 ]
    
    The bridge might miss the display change events when it's powered off.
    This happens when a user changes the external monitor when the system
    is suspended and the embedded controller doesn't not wake AP up.
    
    It's also observed that one DP-to-HDMI bridge doesn't work correctly
    when there is no EDID read after it is powered on.
    
    Drop the cache to force an EDID read after system resume to fix this.
    
    Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240926092931.3870342-2-treapking@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea6a2cc95e49d05a155e8e53109576ee94712275
Author: Macpaul Lin <macpaul.lin@mediatek.com>
Date:   Mon Sep 30 15:54:50 2024 +0800

    ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode
    
    [ Upstream commit 4649cbd97fdae5069e9a71cd7669b62b90e03669 ]
    
    Some fix and updates in the following items:
    1. examples:
       Update generic node name to 'audio-codec' to comply with the
       coming change in 'mt6359.dtsi'. This change is necessary to fix the
       dtbs_check error:
       pmic: 'mt6359codec' does not match any of the regexes: 'pinctrl-[0-9]+'
    
    2. mediatek,dmic-mode:
       After inspecting the .dts and .dtsi files using 'mt6359-codec', it was
       discovered that the definitions of 'two wires' and 'one wire' are
       inverted compared to the DT schema.
       For example, the following boards using MT6359 PMIC:
        - mt8192-asurada.dtsi
        - mt8195-cherry.dtsi
       These boards use the same definitions of 'dmic-mode' as other boards
       using MT6358 PMIC. The meaning of '0' or '1' has been noted as comments
       in the device trees.
    
       Upon examining the code in [1] and [2], it was confirmed that the
       definitions of 'dmic-mode' are consistent between "MT6359 PMIC" and
       "MT6358 PMIC". Therefore, the DT Schema should be correct as is.
    
    References:
    [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6358.c#n1875
    [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6359.c#L1515
    
    Fixes: 539237d1c609 ("dt-bindings: mediatek: mt6359: add codec document")
    Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://patch.msgid.link/20240930075451.14196-1-macpaul.lin@mediatek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6df74efcd46c95f4435d5b4bf35bbc94d49f1a
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Fri Sep 27 16:00:29 2024 +0800

    ASoC: fsl_micfil: fix regmap_write_bits usage
    
    [ Upstream commit 06df673d20230afb0e383e39235a4fa8b9a62464 ]
    
    The last parameter 1 means BIT(0), which should be the
    correct BIT(X).
    
    Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
    Link: https://patch.msgid.link/1727424031-19551-2-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54ea2e51bb2e267fcab6e45c600865d473f5c086
Author: Igor Prusov <ivprusov@salutedevices.com>
Date:   Wed Sep 25 17:52:39 2024 +0300

    dt-bindings: vendor-prefixes: Add NeoFidelity, Inc
    
    [ Upstream commit 5d9e6d6fc1b98c8c22d110ee931b3b233d43cd13 ]
    
    Add vendor prefix for NeoFidelity, Inc
    
    Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://patch.msgid.link/20240925-ntp-amps-8918-8835-v3-1-e2459a8191a6@salutedevices.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ade744bf81b478e78bd1734fcf014bfa5b0d303a
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Thu Jul 11 10:03:44 2024 +0800

    wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2
    
    [ Upstream commit 52db16ec5bae7bd027804265b968259d1a6c3970 ]
    
    In supported_vht_mcs_rate_nss2, the rate for MCS9 & VHT20 is defined as
    {1560, 1733}, this does not align with firmware's definition and therefore
    fails the verification in ath10k_mac_get_rate_flags_vht():
    
            invalid vht params rate 1730 100kbps nss 2 mcs 9
    
    and:
    
            invalid vht params rate 1920 100kbps nss 2 mcs 9
    
    Change it to {1730,  1920} to align with firmware to fix the issue.
    
    Since ath10k_hw_params::supports_peer_stats_info is enabled only for
    QCA6174, this change does not affect other chips.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1
    
    Fixes: 3344b99d69ab ("ath10k: add bitrate parse for peer stats info")
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-8402272788ff@molgen.mpg.de/
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 9360
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://patch.msgid.link/20240711020344.98040-3-quic_bqiang@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 266f9d3b7c1d82e487fb74866d19458eea1c414e
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Thu Jul 11 10:03:43 2024 +0800

    wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1
    
    [ Upstream commit d50886b27850447d90c0cd40c725238097909d1e ]
    
    In supported_vht_mcs_rate_nss1, the rate for MCS9 & VHT20 is defined as
    {780,  867}, this does not align with firmware's definition and therefore
    fails the verification in ath10k_mac_get_rate_flags_vht():
    
            invalid vht params rate 960 100kbps nss 1 mcs 9
    
    Change it to {865,  960} to align with firmware, so this issue could be
    fixed.
    
    Since ath10k_hw_params::supports_peer_stats_info is enabled only for
    QCA6174, this change does not affect other chips.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1
    
    Fixes: 3344b99d69ab ("ath10k: add bitrate parse for peer stats info")
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-8402272788ff@molgen.mpg.de/
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://patch.msgid.link/20240711020344.98040-2-quic_bqiang@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ec51f8404e1fb691e63acdf0a7fa9d6bd10760b
Author: Maíra Canal <mcanal@igalia.com>
Date:   Mon Sep 23 10:55:05 2024 -0300

    drm/v3d: Address race-condition in MMU flush
    
    [ Upstream commit cf1becb7f996a0a23ea2c270cf6bb0911ec3ca1a ]
    
    We must first flush the MMU cache and then, flush the TLB, not the other
    way around. Currently, we can see a race condition between the MMU cache
    and the TLB when running multiple rendering processes at the same time.
    This is evidenced by MMU errors triggered by the IRQ.
    
    Fix the MMU flush order by flushing the MMU cache and then the TLB.
    Also, in order to address the race condition, wait for the MMU cache flush
    to finish before starting the TLB flush.
    
    Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
    Signed-off-by: Maíra Canal <mcanal@igalia.com>
    Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240923141348.2422499-2-mcanal@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 372e43bdc7c1e5c86a3b8ebbfadf3950fa257c12
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 16:30:18 2024 +0800

    drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 40004709a3d3b07041a473a163ca911ef04ab8bd ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 47b1be5c0f4e ("staging: imx/drm: request irq only after adding the crtc")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-4-ruanjinjie@huawei.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6f8ec9cdb81359d4d340e1107b520d288a596fe
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 16:30:16 2024 +0800

    drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 1af01e14db7e0b45ae502d822776a58c86688763 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-2-ruanjinjie@huawei.com
    [DB: fixed the subject]
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53cbeffdd729fa03ba06bf89d51fd4d0c6be9014
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Tue Sep 10 20:43:13 2024 +0800

    wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 9a98dd48b6d834d7a3fe5e8e7b8c3a1d006f9685 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240910124314.698896-3-ruanjinjie@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3496512fe8cb17f214ee65b92f50048b808dc49f
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Tue Sep 10 20:43:12 2024 +0800

    wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit bcd1371bd85e560ccc9159b7747f94bfe43b77a6 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: cd8d3d321285 ("p54spi: p54spi driver")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240910124314.698896-2-ruanjinjie@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa4a24f5b30dcefc7dff4352deb97b061a7591e2
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Tue Aug 6 16:50:29 2024 +0300

    drm/omap: Fix locking in omap_gem_new_dmabuf()
    
    [ Upstream commit e6a1c4037227539373c8cf484ace83833e2ad6a2 ]
    
    omap_gem_new_dmabuf() creates the new gem object, and then takes and
    holds the omap_obj->lock for the rest of the function. This has two
    issues:
    
    - omap_gem_free_object(), which is called in the error paths, also takes
      the same lock, leading to deadlock
    - Even if the above wouldn't happen, in the error cases
      omap_gem_new_dmabuf() still unlocks omap_obj->lock, even after the
      omap_obj has already been freed.
    
    Furthermore, I don't think there's any reason to take the lock at all,
    as the object was just created and not yet shared with anyone else.
    
    To fix all this, drop taking the lock.
    
    Fixes: 3cbd0c587b12 ("drm/omap: gem: Replace struct_mutex usage with omap_obj private lock")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/511b99d7-aade-4f92-bd3e-63163a13d617@stanley.mountain/
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-3-15d31aea0831@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6534234a5f853518dcda8c1878586c1886fa43af
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Tue Aug 6 16:50:27 2024 +0300

    drm/omap: Fix possible NULL dereference
    
    [ Upstream commit a88fee2d67d9b78c24630a987a88ccf886b2498b ]
    
    smatch reports:
    
    drivers/gpu/drm/omapdrm/dss/base.c:176 omapdss_device_disconnect() error: we previously assumed 'src' could be null (see line 169)
    
    This code is mostly from a time when omapdrm had its own display device
    model. I can't honestly remember the details, and I don't think it's
    worth digging in deeply into that for a legacy driver.
    
    However, it looks like we only call omapdss_device_disconnect() and
    omapdss_device_connect() with NULL as the src parameter. We can thus
    drop the src parameter from both functions, and fix the smatch warning.
    
    I don't think omapdss_device_disconnect() ever gets NULL for the dst
    parameter (if it did, we'd crash soon after returning from the
    function), but I have kept the !dst check, just in case, but I added a
    WARN_ON() there.
    
    Also, if the dst parameter can be NULL, we can't always get the struct
    dss_device pointer from dst->dss (which is only used for a debug print).
    To make sure we can't hit that issue, do it similarly to the
    omapdss_device_connect() function: add 'struct dss_device *dss' as the
    first parameter, so that we always have it regardless of the dst.
    
    Fixes: 79107f274b2f ("drm/omap: Add support for drm_bridge")
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-1-15d31aea0831@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70eae50d2156cb6e078d0d78809b49bf2f4c7540
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Sat Sep 14 12:06:03 2024 +0300

    wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
    
    [ Upstream commit 8619593634cbdf5abf43f5714df49b04e4ef09ab ]
    
    I found the following bug in my fuzzer:
    
      UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
      index 255 is out of range for type 'htc_endpoint [22]'
      CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
      Workqueue: events request_firmware_work_func
      Call Trace:
       <TASK>
       dump_stack_lvl+0x180/0x1b0
       __ubsan_handle_out_of_bounds+0xd4/0x130
       htc_issue_send.constprop.0+0x20c/0x230
       ? _raw_spin_unlock_irqrestore+0x3c/0x70
       ath9k_wmi_cmd+0x41d/0x610
       ? mark_held_locks+0x9f/0xe0
       ...
    
    Since this bug has been confirmed to be caused by insufficient verification
    of conn_rsp_epid, I think it would be appropriate to add a range check for
    conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
    
    Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://patch.msgid.link/20240909103855.68006-1-aha310510@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd53f82a1da4ebea8241f30f799ad90091ae72cb
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Jun 21 16:20:55 2024 +0100

    drm/vc4: hvs: Correct logic on stopping an HVS channel
    
    [ Upstream commit 7ab6512e7942889c0962588355cb92424a690be6 ]
    
    When factoring out __vc4_hvs_stop_channel, the logic got inverted from
            if (condition)
              // stop channel
    to
            if (condition)
              goto out
            //stop channel
            out:
    and also changed the exact register writes used to stop the channel.
    
    Correct the logic so that the channel is actually stopped, and revert
    to the original register writes.
    
    Fixes: 6d01a106b4c8 ("drm/vc4: crtc: Move HVS init and close to a function")
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-32-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 151bec2fd015af9cd710026c9ed1e1c5c9cf10c1
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Jun 21 16:20:42 2024 +0100

    drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function
    
    [ Upstream commit d285bb622ebdfaa84f51df3a1abccb87036157ea ]
    
    The debugfs function to dump dlists aborted at 256 bytes,
    when actually the dlist memory is generally significantly
    larger but varies based on SoC.
    
    We already have the correct limit in __vc4_hvs_alloc, so
    store it for use in the debugfs dlist function.
    
    Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists")
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-19-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 253ccf145b55f2d8cb7e2701652b95f8303e7b66
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Jun 21 16:20:41 2024 +0100

    drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer
    
    [ Upstream commit 6d5f76e0544b04ec5bdd2a09c19d90aeeb2cd479 ]
    
    The debug function to display the dlists didn't reset next_entry_start
    when starting each display, so resulting in not stopping the
    list at the correct place.
    
    Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists")
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-18-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ea29bd7d9400d3629683244d609358ed1b12075
Author: Dom Cobley <popcornmix@gmail.com>
Date:   Fri Jun 21 16:20:40 2024 +0100

    drm/vc4: hdmi: Avoid hang with debug registers when suspended
    
    [ Upstream commit 223ee2567a55e4f80315c768d2969e6a3b9fb23d ]
    
    Trying to read /sys/kernel/debug/dri/1/hdmi1_regs
    when the hdmi is disconnected results in a fatal system hang.
    
    This is due to the pm suspend code disabling the dvp clock.
    That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,
    which results in accesses hanging AXI bus.
    
    Protect against this.
    
    Fixes: 25eb441d55d4 ("drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumps")
    Signed-off-by: Dom Cobley <popcornmix@gmail.com>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-17-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5aeb962e44ede74b9db21cd9aad06e773fa02a9
Author: Dave Stevenson <dave.stevenson@raspberrypi.com>
Date:   Fri Jun 21 16:20:38 2024 +0100

    drm/vc4: hvs: Don't write gamma luts on 2711
    
    [ Upstream commit 52efe364d1968ee3e3ed45eb44eb924b63635315 ]
    
    The gamma block has changed in 2711, therefore writing the lut
    in vc4_hvs_lut_load is incorrect.
    
    Whilst the gamma property isn't created for 2711, it is called
    from vc4_hvs_init_channel, so abort if attempted.
    
    Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-15-dave.stevenson@raspberrypi.com
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e9265b25231e82789c998b8ee88dc00a1aa5813
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Aug 29 18:46:40 2024 +0300

    drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused
    
    [ Upstream commit 53bd7c1c0077db533472ae32799157758302ef48 ]
    
    The INTERVAL_TREE_DEFINE() uncoditionally provides a bunch of helper
    functions which in some cases may be not used. This, in particular,
    prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y:
    
    .../drm/drm_mm.c:152:1: error: unused function 'drm_mm_interval_tree_insert' [-Werror,-Wunused-function]
      152 | INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
          | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      153 |                      u64, __subtree_last,
          |                      ~~~~~~~~~~~~~~~~~~~~
      154 |                      START, LAST, static inline, drm_mm_interval_tree)
          |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by marking drm_mm_interval_tree*() functions with __maybe_unused.
    
    See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
    inline functions for W=1 build").
    
    Fixes: 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240829154640.1120050-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c1e2dbb7297d430f25f4cc946d72166c40a6845
Author: Yao Zi <ziyao@disroot.org>
Date:   Mon Nov 18 06:46:39 2024 +0000

    platform/x86: panasonic-laptop: Return errno correctly in show callback
    
    [ Upstream commit 5c7bebc1a3f0661db558d60e14dde27fc216d9dc ]
    
    When an error occurs in sysfs show callback, we should return the errno
    directly instead of formatting it as the result, which produces
    meaningless output and doesn't inform the userspace of the error.
    
    Fixes: 468f96bfa3a0 ("platform/x86: panasonic-laptop: Add support for battery charging threshold (eco mode)")
    Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series")
    Signed-off-by: Yao Zi <ziyao@disroot.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20241118064637.61832-3-ziyao@disroot.org
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61
Author: Li Huafei <lihuafei1@huawei.com>
Date:   Mon Nov 4 22:50:51 2024 +0800

    media: atomisp: Add check for rgby_data memory allocation failure
    
    [ Upstream commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 ]
    
    In ia_css_3a_statistics_allocate(), there is no check on the allocation
    result of the rgby_data memory. If rgby_data is not successfully
    allocated, it may trigger the assert(host_stats->rgby_data) assertion in
    ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
    
    Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
    Signed-off-by: Li Huafei <lihuafei1@huawei.com>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20241104145051.3088231-1-lihuafei1@huawei.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18028c437ed435e59ce075dd2f20cf91f3a64a6d
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Fri May 26 07:29:34 2023 +0100

    media: venus: provide ctx queue lock for ioctl synchronization
    
    [ Upstream commit 34318b808ef20cdddd4e187ea2df0455936cf61b ]
    
    Video device has to provide a lock so that __video_do_ioctl()
    can serialize IOCTL calls. Introduce a dedicated venus_inst
    mutex for the purpose of vb2 operations synchronization.
    
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Stable-dep-of: 6c9934c5a00a ("media: venus: fix enc/dec destruction order")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23f63457f01d7f23ee50fdac48129b07f574da79
Author: Dikshita Agarwal <quic_dikshita@quicinc.com>
Date:   Wed Apr 5 12:45:23 2023 +0530

    venus: venc: add handling for VIDIOC_ENCODER_CMD
    
    [ Upstream commit 7493db46e4c4aa5126dd32f8eae12a4cdcf7a401 ]
    
    Add handling for below commands in encoder:
    1. V4L2_ENC_CMD_STOP
    2. V4L2_ENC_CMD_START
    
    Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
    Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: 6c9934c5a00a ("media: venus: fix enc/dec destruction order")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06258e57fee253f4046d3a6a86d7fde09f596eac
Author: Luo Qiu <luoqiu@kylinsec.com.cn>
Date:   Fri Nov 1 11:21:15 2024 +0800

    firmware: arm_scpi: Check the DVFS OPP count returned by the firmware
    
    [ Upstream commit 109aa654f85c5141e813b2cd1bd36d90be678407 ]
    
    Fix a kernel crash with the below call trace when the SCPI firmware
    returns OPP count of zero.
    
    dvfs_info.opp_count may be zero on some platforms during the reboot
    test, and the kernel will crash after dereferencing the pointer to
    kcalloc(info->count, sizeof(*opp), GFP_KERNEL).
    
      |  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
      |  Mem abort info:
      |    ESR = 0x96000004
      |    Exception class = DABT (current EL), IL = 32 bits
      |    SET = 0, FnV = 0
      |    EA = 0, S1PTW = 0
      |  Data abort info:
      |    ISV = 0, ISS = 0x00000004
      |    CM = 0, WnR = 0
      |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
      |  [0000000000000028] pgd=0000000000000000
      |  Internal error: Oops: 96000004 [#1] SMP
      |  scpi-hwmon: probe of PHYT000D:00 failed with error -110
      |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
      |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
      |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
      |  pstate: 60000005 (nZCv daif -PAN -UAO)
      |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
      |  lr : clk_register+0x438/0x720
      |  Call trace:
      |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
      |   devm_clk_hw_register+0x50/0xa0
      |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
      |   scpi_clocks_probe+0x528/0x70c [clk_scpi]
      |   platform_drv_probe+0x58/0xa8
      |   really_probe+0x260/0x3d0
      |   driver_probe_device+0x12c/0x148
      |   device_driver_attach+0x74/0x98
      |   __driver_attach+0xb4/0xe8
      |   bus_for_each_dev+0x88/0xe0
      |   driver_attach+0x30/0x40
      |   bus_add_driver+0x178/0x2b0
      |   driver_register+0x64/0x118
      |   __platform_driver_register+0x54/0x60
      |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
      |   do_one_initcall+0x54/0x220
      |   do_init_module+0x54/0x1c8
      |   load_module+0x14a4/0x1668
      |   __se_sys_finit_module+0xf8/0x110
      |   __arm64_sys_finit_module+0x24/0x30
      |   el0_svc_common+0x78/0x170
      |   el0_svc_handler+0x38/0x78
      |   el0_svc+0x8/0x340
      |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
      |  ---[ end trace 06feb22469d89fa8 ]---
      |  Kernel panic - not syncing: Fatal exception
      |  SMP: stopping secondary CPUs
      |  Kernel Offset: disabled
      |  CPU features: 0x10,a0002008
      |  Memory Limit: none
    
    Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
    Signed-off-by: Luo Qiu <luoqiu@kylinsec.com.cn>
    Message-Id: <55A2F7A784391686+20241101032115.275977-1-luoqiu@kylinsec.com.cn>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07121977cc7dc2e10d1ffd0aca76ac642a109880
Author: Reinette Chatre <reinette.chatre@intel.com>
Date:   Thu Oct 24 14:18:41 2024 -0700

    selftests/resctrl: Protect against array overrun during iMC config parsing
    
    [ Upstream commit 48ed4e799e8fbebae838dca404a8527763d41191 ]
    
    The MBM and MBA tests need to discover the event and umask with which to
    configure the performance event used to measure read memory bandwidth.
    This is done by parsing the
    /sys/bus/event_source/devices/uncore_imc_<imc instance>/events/cas_count_read
    file for each iMC instance that contains the formatted
    output: "event=<event>,umask=<umask>"
    
    Parsing of cas_count_read contents is done by initializing an array of
    MAX_TOKENS elements with tokens (deliminated by "=,") from this file.
    Remove the unnecessary append of a delimiter to the string needing to be
    parsed. Per the strtok() man page: "delimiter bytes at the start or end of
    the string are ignored". This has no impact on the token placement within
    the array.
    
    After initialization, the actual event and umask is determined by
    parsing the tokens directly following the "event" and "umask" tokens
    respectively.
    
    Iterating through the array up to index "i < MAX_TOKENS" but then
    accessing index "i + 1" risks array overrun during the final iteration.
    Avoid array overrun by ensuring that the index used within for
    loop will always be valid.
    
    Fixes: 1d3f08687d76 ("selftests/resctrl: Read memory bandwidth from perf IMC counter and from resctrl file system")
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5e0980fcdd51262650cefb325ea655c36d5907c
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Oct 30 15:02:22 2024 +0800

    arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed regulators
    
    [ Upstream commit aaecb1da58a72bfbd2c35d4aadc43caa02f11862 ]
    
    When the fixed regulators for the LCD panel and DP bridge were added,
    their supplies were not modeled in. These, except for the 1.0V supply,
    are just load switches, and need and have a supply.
    
    Add the supplies for each of the fixed regulators.
    
    Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20241030070224.1006331-4-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6441c359d8dc1debc4fb4de86888b8f234999189
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Oct 30 15:02:21 2024 +0800

    arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names
    
    [ Upstream commit c4e8cf13f1740037483565d5b802764e2426515b ]
    
    Some of the regulator supplies for the MIPI-DPI-to-DP bridge and their
    associated nodes are incorrectly named. In particular, the 1.0V supply
    was modeled as a 1.2V supply.
    
    Fix all the incorrect names, and also fix the voltage of the 1.0V
    regulator.
    
    Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20241030070224.1006331-3-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21030e4c7f5025ee86fb858351826d0509b473f6
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Wed Dec 28 19:32:04 2022 +0800

    arm64: dts: mt8183: jacuzzi: Move panel under aux-bus
    
    [ Upstream commit 474c162878ba3dbd620538d129f576f2bca7b9e1 ]
    
    Read edp panel edid through aux bus, which is a more preferred way. Also
    use a more generic compatible since each jacuzzi models use different
    panels.
    
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Link: https://lore.kernel.org/r/20221228113204.1551180-1-hsinyi@chromium.org
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Stable-dep-of: c4e8cf13f174 ("arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46cb2dc1b05c5a508cf143d02303682b1a920b10
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Nov 1 18:55:53 2024 +0200

    regmap: irq: Set lockdep class for hierarchical IRQ domains
    
    [ Upstream commit 953e549471cabc9d4980f1da2e9fa79f4c23da06 ]
    
    Lockdep gives a false positive splat as it can't distinguish the lock
    which is taken by different IRQ descriptors from different IRQ chips
    that are organized in a way of a hierarchy:
    
       ======================================================
       WARNING: possible circular locking dependency detected
       6.12.0-rc5-next-20241101-00148-g9fabf8160b53 #562 Tainted: G        W
       ------------------------------------------------------
       modprobe/141 is trying to acquire lock:
       ffff899446947868 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}, at: regmap_update_bits_base+0x33/0x90
    
       but task is already holding lock:
       ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790
    
       which lock already depends on the new lock.
    
       -> #3 (&d->lock){+.+.}-{4:4}:
       -> #2 (&desc->request_mutex){+.+.}-{4:4}:
       -> #1 (ipclock){+.+.}-{4:4}:
       -> #0 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}:
    
       Chain exists of:
         intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock --> &desc->request_mutex --> &d->lock
    
        Possible unsafe locking scenario:
    
              CPU0                    CPU1
              ----                    ----
         lock(&d->lock);
                                      lock(&desc->request_mutex);
                                      lock(&d->lock);
         lock(intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock);
    
        *** DEADLOCK ***
    
       3 locks held by modprobe/141:
        #0: ffff8994419368f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xf6/0x250
        #1: ffff89944690b250 (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0x1a2/0x790
        #2: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790
    
    Set a lockdep class when we map the IRQ so that it doesn't warn about
    a lockdep bug that doesn't exist.
    
    Fixes: 4af8be67fd99 ("regmap: Convert regmap_irq to use irq_domain")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://patch.msgid.link/20241101165553.4055617-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 321e4f946639dd65a468bc13adf868036d0a9633
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Sep 20 17:11:35 2024 +0800

    spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​
    
    [ Upstream commit 2219576883e709737f3100aa9ded84976be49bd7 ]
    
    It's important to undo pm_runtime_use_autosuspend() with
    pm_runtime_dont_use_autosuspend() at driver exit time.
    
    So, call pm_runtime_dont_use_autosuspend() at driver exit time
    to fix it.
    
    Fixes: 9e3a000362ae ("spi: zynqmp: Add pm runtime support")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://patch.msgid.link/20240920091135.2741574-1-ruanjinjie@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c61c302034282cd302e229aa17da6d1ab39b1b4
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Oct 4 05:53:59 2024 -0700

    spi: tegra210-quad: Avoid shift-out-of-bounds
    
    [ Upstream commit f399051ec1ff02e74ae5c2517aed2cc486fd005b ]
    
    A shift-out-of-bounds issue was identified by UBSAN in the
    tegra_qspi_fill_tx_fifo_from_client_txbuf() function.
    
             UBSAN: shift-out-of-bounds in drivers/spi/spi-tegra210-quad.c:345:27
             shift exponent 32 is too large for 32-bit type 'u32' (aka 'unsigned int')
             Call trace:
              tegra_qspi_start_cpu_based_transfer
    
    The problem arises when shifting the contents of tx_buf left by 8 times
    the value of i, which can exceed 4 and result in an exponent larger than
    32 bits.
    
    Resolve this by restrict the value of i to be less than 4, preventing
    the shift operation from overflowing.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller")
    Link: https://patch.msgid.link/20241004125400.1791089-1-leitao@debian.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aecbbaf2c0779cd75c43636576ba351c1374bad3
Author: Zhang Zekun <zhangzekun11@huawei.com>
Date:   Thu Oct 24 11:04:41 2024 +0800

    pmdomain: ti-sci: Add missing of_node_put() for args.np
    
    [ Upstream commit afc2331ef81657493c074592c409dac7c3cb8ccc ]
    
    of_parse_phandle_with_args() needs to call of_node_put() to decrement
    the refcount of args.np. So, Add the missing of_node_put() in the loop.
    
    Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one")
    Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Message-ID: <20241024030442.119506-2-zhangzekun11@huawei.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a2f0e663cf9515197df10fdc7e3906c7385ddda
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Mon Oct 7 23:29:16 2024 +0100

    ARM: dts: cubieboard4: Fix DCDC5 regulator constraints
    
    [ Upstream commit dd36ad71ad65968f97630808bc8d605c929b128e ]
    
    The DCDC5 voltage rail in the X-Powers AXP809 PMIC has a resolution of
    50mV, so the currently enforced limits of 1.475 and 1.525 volts cannot
    be set, when the existing regulator value is beyond this range.
    
    This will lead to the whole regulator driver to give up and fail
    probing, which in turn will hang the system, as essential devices depend
    on the PMIC.
    In this case a bug in U-Boot set the voltage to 1.75V (meant for DCDC4),
    and the AXP driver's attempt to correct this lead to this error:
    ==================
    [    4.447653] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded
    [    4.450066] vcc-dram: Bringing 1750000uV into 1575000-1575000uV
    [    4.460272] vcc-dram: failed to apply 1575000-1575000uV constraint: -EINVAL
    [    4.474788] axp20x-regulator axp20x-regulator.0: Failed to register dcdc5
    [    4.482276] axp20x-regulator axp20x-regulator.0: probe with driver axp20x-regulator failed with error -22
    ==================
    
    Set the limits to values that can be programmed, so any correction will
    be successful.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Fixes: 1e1dea72651b ("ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and regulators")
    Link: https://patch.msgid.link/20241007222916.19013-1-andre.przywara@arm.com
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1649f1224b2a481cd27dad2252be5626bfd33a5c
Author: Clark Wang <xiaoning.wang@nxp.com>
Date:   Tue Oct 8 15:41:23 2024 -0400

    pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle
    
    [ Upstream commit a25351e4c7740eb22561a3ee4ef17611c6f410b0 ]
    
    Implement workaround for ERR051198
    (https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf)
    
    PWM output may not function correctly if the FIFO is empty when a new SAR
    value is programmed.
    
    Description:
      When the PWM FIFO is empty, a new value programmed to the PWM Sample
      register (PWM_PWMSAR) will be directly applied even if the current timer
      period has not expired. If the new SAMPLE value programmed in the
      PWM_PWMSAR register is less than the previous value, and the PWM counter
      register (PWM_PWMCNR) that contains the current COUNT value is greater
      than the new programmed SAMPLE value, the current period will not flip
      the level. This may result in an output pulse with a duty cycle of 100%.
    
    Workaround:
      Program the current SAMPLE value in the PWM_PWMSAR register before
      updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR
      register. This will ensure that the new SAMPLE value is modified during
      a non-empty FIFO, and can be successfully updated after the period
      expires.
    
    Write the old SAR value before updating the new duty cycle to SAR. This
    avoids writing the new value into an empty FIFO.
    
    This only resolves the issue when the PWM period is longer than 2us
    (or <500kHz) because write register is not quick enough when PWM period is
    very short.
    
    Reproduce steps:
      cd /sys/class/pwm/pwmchip1/pwm0
      echo 2000000000 > period     # It is easy to observe by using long period
      echo 1000000000 > duty_cycle
      echo 1 > enable
      echo       8000 > duty_cycle # One full high pulse will be seen by scope
    
    Fixes: 166091b1894d ("[ARM] MXC: add pwm driver for i.MX SoCs")
    Reviewed-by: Jun Li <jun.li@nxp.com>
    Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com
    Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 195b1a022c90b57cd9aba7df261d8bcffb09e97c
Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
Date:   Fri Oct 25 16:03:51 2024 +0800

    arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns
    
    [ Upstream commit 6ff2d45f2121c698a57c959ae21885a048615908 ]
    
    Add i2c2's i2c-scl-internal-delay-ns.
    
    Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-4-9be1bcaf35e0@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1340d82aa0a6d0010291c6770fd986b521113a7d
Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
Date:   Fri Oct 25 16:03:50 2024 +0800

    arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns
    
    [ Upstream commit bd0eb3b1f7aee698b86513edf10a50e2d0c7cb14 ]
    
    Add i2c2's i2c-scl-internal-delay-ns.
    
    Fixes: 52e84f233459 ("arm64: dts: mt8183: Add kukui-jacuzzi-cozmo board")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-3-9be1bcaf35e0@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da7b2b7be2b039d0d315486353bb78a23b8aff44
Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
Date:   Fri Oct 25 16:03:49 2024 +0800

    arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns
    
    [ Upstream commit 85af64983889c621e8868b744c8ca03bd5038c02 ]
    
    Add i2c2's i2c-scl-internal-delay-ns.
    
    Fixes: dd6e3b06214f ("arm64: dts: mt8183: Add kukui-jacuzzi-burnet board")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-2-9be1bcaf35e0@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 449aa993c4d12450f8a56bdc3518f2d8fb5acbad
Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
Date:   Fri Oct 25 16:03:48 2024 +0800

    arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns
    
    [ Upstream commit c802db127dfb9602aaa9338e433c0553d34f1a9c ]
    
    Add i2c2's i2c-scl-internal-delay-ns.
    
    Fixes: 6cd7fdc8c530 ("arm64: dts: mt8183: Add kukui-jacuzzi-fennel board")
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com>
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by:
    Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-1-9be1bcaf35e0@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c222df370ed49dd8a7183de3a1a3af92e61d87b
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Oct 18 08:15:20 2024 +0000

    cgroup/bpf: only cgroup v2 can be attached by bpf programs
    
    [ Upstream commit 2190df6c91373fdec6db9fc07e427084f232f57e ]
    
    Only cgroup v2 can be attached by bpf programs, so this patch introduces
    that cgroup_bpf_inherit and cgroup_bpf_offline can only be called in
    cgroup v2, and this can fix the memleak mentioned by commit 04f8ef5643bc
    ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline"), which
    has been reverted.
    
    Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path")
    Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself")
    Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e5e64d28071d207d561bb5197e39a2118782bf
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Oct 18 08:15:19 2024 +0000

    Revert "cgroup: Fix memory leak caused by missing cgroup_bpf_offline"
    
    [ Upstream commit feb301c60970bd2a1310a53ce2d6e4375397a51b ]
    
    This reverts commit 04f8ef5643bcd8bcde25dfdebef998aea480b2ba.
    
    Only cgroup v2 can be attached by cgroup by BPF programs. Revert this
    commit and cgroup_bpf_inherit and cgroup_bpf_offline won't be called in
    cgroup v1. The memory leak issue will be fixed with next patch.
    
    Fixes: 04f8ef5643bc ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline")
    Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34772c3f1a38d1081bb779090b0d9166cbfcd7e6
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Fri Oct 18 16:20:00 2024 +0800

    arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source trackpad
    
    [ Upstream commit f766fae08f6a2eaeb45d8d2c053724c91526835c ]
    
    The Hana device has a second source option trackpad, but it is missing
    its regulator supply. It only works because the regulator is marked as
    always-on.
    
    Add the regulator supply, but leave out the post-power-on delay. Instead,
    document the post-power-on delay along with the reason for not adding
    it in a comment.
    
    Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241018082001.1296963-1-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe6370363dc6692d5b37eea5a6aa9de089e34628
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Mon Sep 9 08:33:47 2024 +0000

    arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4
    
    [ Upstream commit edbde4923f208aa83abb48d4b2463299e5fc2586 ]
    
    The address of eeprom should be 50.
    
    Fixes: ff33d889567e ("arm64: dts: mt8183: Add kukui kodama board")
    Fixes: d1eaf77f2c66 ("arm64: dts: mt8183: Add kukui kakadu board")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240909-eeprom-v1-2-1ed2bc5064f4@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98d36e06c52f7b54bc70a254e3cd82529b67a961
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Mon Sep 9 08:33:46 2024 +0000

    arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4
    
    [ Upstream commit e9c60c34948662b5d47573490ee538439b29e462 ]
    
    The address of eeprom should be 50.
    
    Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/20240909-eeprom-v1-1-1ed2bc5064f4@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b710262205d7ffc6d24671c7b9ff3b237c5ceaa
Author: Gregory Price <gourry@gourry.net>
Date:   Fri Sep 13 19:19:51 2024 -0400

    tpm: fix signed/unsigned bug when checking event logs
    
    [ Upstream commit e6d654e9f5a97742cfe794b1c4bb5d3fb2d25e98 ]
    
    A prior bugfix that fixes a signed/unsigned error causes
    another signed unsigned error.
    
    A situation where log_tbl->size is invalid can cause the
    size passed to memblock_reserve to become negative.
    
    log_size from the main event log is an unsigned int, and
    the code reduces to the following
    
    u64 value = (int)unsigned_value;
    
    This results in sign extension, and the value sent to
    memblock_reserve becomes effectively negative.
    
    Fixes: be59d57f9806 ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero")
    Signed-off-by: Gregory Price <gourry@gourry.net>
    Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16c888161c31f257e4a598c0e3fcdea6ac00e86d
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Tue Oct 8 18:01:34 2024 +0200

    mmc: mmc_spi: drop buggy snprintf()
    
    [ Upstream commit 328bda09cc91b3d93bc64f4a4dadc44313dd8140 ]
    
    GCC 13 complains about the truncated output of snprintf():
    
    drivers/mmc/host/mmc_spi.c: In function ‘mmc_spi_response_get’:
    drivers/mmc/host/mmc_spi.c:227:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
      227 |         snprintf(tag, sizeof(tag), "  ... CMD%d response SPI_%s",
          |                                                                ^
    drivers/mmc/host/mmc_spi.c:227:9: note: ‘snprintf’ output between 26 and 43 bytes into a destination of size 32
      227 |         snprintf(tag, sizeof(tag), "  ... CMD%d response SPI_%s",
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      228 |                 cmd->opcode, maptype(cmd));
    
    Drop it and fold the string it generates into the only place where it's
    emitted - the dev_dbg() call at the end of the function.
    
    Fixes: 15a0580ced08 ("mmc_spi host driver")
    Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/r/20241008160134.69934-1-brgl@bgdev.pl
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0a9c6ccaf88c4701787f61ecd2ec0eb014a0677
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Sep 30 10:51:31 2024 +0300

    soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()
    
    [ Upstream commit 78261cb08f06c93d362cab5c5034bf5899bc7552 ]
    
    This loop is supposed to break if the frequency returned from
    clk_round_rate() is the same as on the previous iteration.  However,
    that check doesn't make sense on the first iteration through the loop.
    It leads to reading before the start of these->clk_perf_tbl[] array.
    
    Fixes: eddac5af0654 ("soc: qcom: Add GENI based QUP Wrapper driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/8cd12678-f44a-4b16-a579-c8f11175ee8c@stanley.mountain
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f177f3c11618034feb9af816a228ec9d99421063
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Thu Sep 12 11:41:47 2024 +0800

    soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 16a0a69244240cfa32c525c021c40f85e090557a ]
    
    If request_irq() fails in sr_late_init(), there is no need to enable
    the irq, and if it succeeds, disable_irq() after request_irq() still has
    a time gap in which interrupts can come.
    
    request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when
    request IRQ.
    
    Fixes: 1279ba5916f6 ("OMAP3+: SR: disable interrupt by default")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20240912034147.3014213-1-ruanjinjie@huawei.com
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c39349952a36fe3f662bd1261170b58164ac4c2
Author: Macpaul Lin <macpaul.lin@mediatek.com>
Date:   Wed Oct 2 13:16:16 2024 +0800

    arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node
    
    [ Upstream commit c14ab45f5d458073248ddc62d31045d5d616806f ]
    
    The infracfg_ao node in mt8195.dtsi was causing a dtbs_check error.
    The error message was:
    
    syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon',
                     'simple-mfd'] is too long
    
    To resolve this, remove 'simple-mfd' from the 'compatible' property of the
    infracfg_ao node.
    
    Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board")
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20241002051620.2050-1-macpaul.lin@mediatek.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a3e9bf08cdb3fa1e35faafa7358ecd35e54c71e
Author: Michal Simek <michal.simek@amd.com>
Date:   Wed Jun 19 14:11:32 2024 +0200

    microblaze: Export xmb_manager functions
    
    [ Upstream commit badf752b5e4b17d281f93f409d4718388ff912e6 ]
    
    When TMR_MANAGER is enabled as module there is a need to export functions
    which are present in architecture code.
    
    It has been found by running:
    make W=1 C=1 allmodconfig
    sed -i -e 's/WERROR=y/WERROR=n/g' .config
    make C=1 W=1
    
    which errors out like this:
    ERROR: modpost: "xmb_manager_register" [drivers/misc/xilinx_tmr_manager.ko] undefined!
    ERROR: modpost: "xmb_inject_err" [drivers/misc/xilinx_tmr_inject.ko] undefined!
    
    Fixes: a5e3aaa654c1 ("microblaze: Add xmb_manager_register function")
    Reported-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/e322dbbbde0feef83f44304ea13249d365d1dc5f.1718799090.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 272168927f38bda46f6c1ed5f40de97689e7a5d2
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Sat Jul 6 14:51:55 2024 +0800

    drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()
    
    [ Upstream commit 44ed4f90a97ff6f339e50ac01db71544e0990efc ]
    
    If we fail to allocate memory for cb_data by kmalloc, the memory
    allocation for eve_data is never freed, add the missing kfree()
    in the error handling path.
    
    Fixes: 05e5ba40ea7a ("driver: soc: xilinx: Add support of multiple callbacks for same event in event management driver")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20240706065155.452764-1-cuigaosheng1@huawei.com
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d89ff55ff06e841ef1955615ff456061931aaea
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Sep 6 10:28:28 2024 +0800

    spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 003c7e01916c5e2af95add9b0cbda2e6163873e8 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 9728fb3ce117 ("spi: lpspi: disable lpspi module irq in DMA mode")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://patch.msgid.link/20240906022828.891812-1-ruanjinjie@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99b60d5a7304070aa001b7fe0c82b2ba42108891
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed May 31 09:28:49 2023 +0200

    spi: spi-fsl-lpspi: downgrade log level for pio mode
    
    [ Upstream commit d5786c88cacbb859f465e8e93c26154585c1008d ]
    
    Having no DMA is not an error. The simplest reason is not having it
    configured. SPI will still be usable, so raise a warning instead to
    get still some attention.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20230531072850.739021-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 003c7e01916c ("spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 713e85376bac76b5dc6d8c6ade6a3a40870107f9
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Thu Oct 31 13:54:23 2024 +0100

    clocksource/drivers/timer-ti-dm: Fix child node refcount handling
    
    [ Upstream commit e5cfc0989d9a2849c51c720a16b90b2c061a1aeb ]
    
    of_find_compatible_node() increments the node's refcount, and it must be
    decremented again with a call to of_node_put() when the pointer is no
    longer required to avoid leaking the resource.
    
    Instead of adding the missing calls to of_node_put() in all execution
    paths, use the cleanup attribute for 'arm_timer' by means of the
    __free() macro, which automatically calls of_node_put() when the
    variable goes out of scope.
    
    Fixes: 25de4ce5ed02 ("clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20241031-timer-ti-dm-systimer-of_node_put-v3-1-063ee822b73a@gmail.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5b6e8a1bac8f2ffc2f33a0f9423987a6b2a489e
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Oct 1 12:23:56 2024 +0100

    clocksource/drivers:sp804: Make user selectable
    
    [ Upstream commit 0309f714a0908e947af1c902cf6a330cb593e75e ]
    
    The sp804 is currently only user selectable if COMPILE_TEST, this was
    done by commit dfc82faad725 ("clocksource/drivers/sp804: Add
    COMPILE_TEST to CONFIG_ARM_TIMER_SP804") in order to avoid it being
    spuriously offered on platforms that won't have the hardware since it's
    generally only seen on Arm based platforms.  This config is overly
    restrictive, while platforms that rely on the SP804 do select it in
    their Kconfig there are others such as the Arm fast models which have a
    SP804 available but currently unused by Linux.  Relax the dependency to
    allow it to be user selectable on arm and arm64 to avoid surprises and
    in case someone comes up with a use for extra timer hardware.
    
    Fixes: dfc82faad725 ("clocksource/drivers/sp804: Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804")
    Reported-by: Ross Burton <ross.burton@arm.com>
    Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20241001-arm64-vexpress-sp804-v3-1-0a2d3f7883e4@kernel.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19770c1c0e878727f78aaa9797ddcb4286cb38b2
Author: Marco Elver <elver@google.com>
Date:   Mon Nov 4 16:43:09 2024 +0100

    kcsan, seqlock: Fix incorrect assumption in read_seqbegin()
    
    [ Upstream commit 183ec5f26b2fc97a4a9871865bfe9b33c41fddb2 ]
    
    During testing of the preceding changes, I noticed that in some cases,
    current->kcsan_ctx.in_flat_atomic remained true until task exit. This is
    obviously wrong, because _all_ accesses for the given task will be
    treated as atomic, resulting in false negatives i.e. missed data races.
    
    Debugging led to fs/dcache.c, where we can see this usage of seqlock:
    
            struct dentry *d_lookup(const struct dentry *parent, const struct qstr *name)
            {
                    struct dentry *dentry;
                    unsigned seq;
    
                    do {
                            seq = read_seqbegin(&rename_lock);
                            dentry = __d_lookup(parent, name);
                            if (dentry)
                                    break;
                    } while (read_seqretry(&rename_lock, seq));
            [...]
    
    As can be seen, read_seqretry() is never called if dentry != NULL;
    consequently, current->kcsan_ctx.in_flat_atomic will never be reset to
    false by read_seqretry().
    
    Give up on the wrong assumption of "assume closing read_seqretry()", and
    rely on the already-present annotations in read_seqcount_begin/retry().
    
    Fixes: 88ecd153be95 ("seqlock, kcsan: Add annotations for KCSAN")
    Signed-off-by: Marco Elver <elver@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241104161910.780003-6-elver@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c0d57df48fb02845b33b93a1f7dfe77bc7736a9
Author: Marco Elver <elver@google.com>
Date:   Mon Nov 4 16:43:07 2024 +0100

    kcsan, seqlock: Support seqcount_latch_t
    
    [ Upstream commit 5c1806c41ce0a0110db5dd4c483cf2dc28b3ddf0 ]
    
    While fuzzing an arm64 kernel, Alexander Potapenko reported:
    
    | BUG: KCSAN: data-race in ktime_get_mono_fast_ns / timekeeping_update
    |
    | write to 0xffffffc082e74248 of 56 bytes by interrupt on cpu 0:
    |  update_fast_timekeeper kernel/time/timekeeping.c:430 [inline]
    |  timekeeping_update+0x1d8/0x2d8 kernel/time/timekeeping.c:768
    |  timekeeping_advance+0x9e8/0xb78 kernel/time/timekeeping.c:2344
    |  update_wall_time+0x18/0x38 kernel/time/timekeeping.c:2360
    |  [...]
    |
    | read to 0xffffffc082e74258 of 8 bytes by task 5260 on cpu 1:
    |  __ktime_get_fast_ns kernel/time/timekeeping.c:372 [inline]
    |  ktime_get_mono_fast_ns+0x88/0x174 kernel/time/timekeeping.c:489
    |  init_srcu_struct_fields+0x40c/0x530 kernel/rcu/srcutree.c:263
    |  init_srcu_struct+0x14/0x20 kernel/rcu/srcutree.c:311
    |  [...]
    |
    | value changed: 0x000002f875d33266 -> 0x000002f877416866
    |
    | Reported by Kernel Concurrency Sanitizer on:
    | CPU: 1 UID: 0 PID: 5260 Comm: syz.2.7483 Not tainted 6.12.0-rc3-dirty #78
    
    This is a false positive data race between a seqcount latch writer and a reader
    accessing stale data. Since its introduction, KCSAN has never understood the
    seqcount_latch interface (due to being unannotated).
    
    Unlike the regular seqlock interface, the seqcount_latch interface for latch
    writers never has had a well-defined critical section, making it difficult to
    teach tooling where the critical section starts and ends.
    
    Introduce an instrumentable (non-raw) seqcount_latch interface, with
    which we can clearly denote writer critical sections. This both helps
    readability and tooling like KCSAN to understand when the writer is done
    updating all latch copies.
    
    Fixes: 88ecd153be95 ("seqlock, kcsan: Add annotations for KCSAN")
    Reported-by: Alexander Potapenko <glider@google.com>
    Co-developed-by: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Signed-off-by: Marco Elver <elver@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20241104161910.780003-4-elver@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb83772959a4465375cbe4bd02a02b2d2e354239
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri May 19 12:20:59 2023 +0200

    seqlock/latch: Provide raw_read_seqcount_latch_retry()
    
    [ Upstream commit d16317de9b412aa7bd3598c607112298e36b4352 ]
    
    The read side of seqcount_latch consists of:
    
      do {
        seq = raw_read_seqcount_latch(&latch->seq);
        ...
      } while (read_seqcount_latch_retry(&latch->seq, seq));
    
    which is asymmetric in the raw_ department, and sure enough,
    read_seqcount_latch_retry() includes (explicit) instrumentation where
    raw_read_seqcount_latch() does not.
    
    This inconsistency becomes a problem when trying to use it from
    noinstr code. As such, fix it by renaming and re-implementing
    raw_read_seqcount_latch_retry() without the instrumentation.
    
    Specifically the instrumentation in question is kcsan_atomic_next(0)
    in do___read_seqcount_retry(). Loosing this annotation is not a
    problem because raw_read_seqcount_latch() does not pass through
    kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX).
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Tested-by: Michael Kelley <mikelley@microsoft.com>  # Hyper-V
    Link: https://lore.kernel.org/r/20230519102715.233598176@infradead.org
    Stable-dep-of: 5c1806c41ce0 ("kcsan, seqlock: Support seqcount_latch_t")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b96f1d03a0fcd343c2000c0bd9a92796a906087
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Fri Oct 25 13:01:41 2024 +0200

    time: Fix references to _msecs_to_jiffies() handling of values
    
    [ Upstream commit 92b043fd995a63a57aae29ff85a39b6f30cd440c ]
    
    The details about the handling of the "normal" values were moved
    to the _msecs_to_jiffies() helpers in commit ca42aaf0c861 ("time:
    Refactor msecs_to_jiffies"). However, the same commit still mentioned
    __msecs_to_jiffies() in the added documentation.
    
    Thus point to _msecs_to_jiffies() instead.
    
    Fixes: ca42aaf0c861 ("time: Refactor msecs_to_jiffies")
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/all/20241025110141.157205-2-ojeda@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc50e498e3b53efd05e66847b72d61c1a22efada
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Thu Oct 24 12:59:38 2024 +0200

    thermal/lib: Fix memory leak on error in thermal_genl_auto()
    
    [ Upstream commit 7569406e95f2353070d88ebc88e8c13698542317 ]
    
    The function thermal_genl_auto() does not free the allocated message
    in the error path. Fix that by putting a out label and jump to it
    which will free the message instead of directly returning an error.
    
    Fixes: 47c4b0de080a ("tools/lib/thermal: Add a thermal library")
    Reported-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Link: https://patch.msgid.link/20241024105938.1095358-1-daniel.lezcano@linaro.org
    [ rjw: Fixed up the !msg error path, added Fixes tag ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad9210452a7b05a3dba8bebb443c3b28e7c35aaf
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Tue Oct 22 17:51:43 2024 +0200

    tools/lib/thermal: Make more generic the command encoding function
    
    [ Upstream commit 24b216b2d13568c703a76137ef54a2a9531a71d8 ]
    
    The thermal netlink has been extended with more commands which require
    an encoding with more information. The generic encoding function puts
    the thermal zone id with the command name. It is the unique
    parameters.
    
    The next changes will provide more parameters to the command. Set the
    scene for those new parameters by making the encoding function more
    generic.
    
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Link: https://patch.msgid.link/20241022155147.463475-4-daniel.lezcano@linaro.org
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 7569406e95f2 ("thermal/lib: Fix memory leak on error in thermal_genl_auto()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d0c18d84ad034f1ddfca7dd44c9655b9da497cc
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Nov 8 18:22:27 2024 +0100

    crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()
    
    [ Upstream commit 572b7cf08403b6c67dfe0dc3e0f2efb42443254f ]
    
    If do_cpt_init() fails, a previous dma_alloc_coherent() call needs to be
    undone.
    
    Add the needed dma_free_coherent() before returning.
    
    Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05f0a3f5477ecaa1cf46448504afe9e7c2e96fcc
Author: Chen Ridong <chenridong@huawei.com>
Date:   Mon Nov 4 12:17:45 2024 +0000

    crypto: bcm - add error check in the ahash_hmac_init function
    
    [ Upstream commit 19630cf57233e845b6ac57c9c969a4888925467b ]
    
    The ahash_init functions may return fails. The ahash_hmac_init should
    not return ok when ahash_init returns error. For an example, ahash_init
    will return -ENOMEM when allocation memory is error.
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e951b29237e3cdf65d3bdff29078b84aa7fee27d
Author: Chen Ridong <chenridong@huawei.com>
Date:   Mon Nov 4 12:15:11 2024 +0000

    crypto: caam - add error check to caam_rsa_set_priv_key_form
    
    [ Upstream commit b64140c74e954f1db6eae5548ca3a1f41b6fad79 ]
    
    The caam_rsa_set_priv_key_form did not check for memory allocation errors.
    Add the checks to the caam_rsa_set_priv_key_form functions.
    
    Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4771ad8c70fe2a48fd34384540ed610335407215
Author: Lifeng Zheng <zhenglifeng1@huawei.com>
Date:   Wed Nov 13 18:33:09 2024 +0800

    ACPI: CPPC: Fix _CPC register setting issue
    
    [ Upstream commit 2388b266c9fcc7c9169ba85c7f9ebe325b7622d7 ]
    
    Since commit 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC
    registers cannot be changed from 1 to 0.
    
    It turns out that there is an extra OR after MASK_VAL_WRITE(), which
    has already ORed prev_val with the register mask.
    
    Remove the extra OR to fix the problem.
    
    Fixes: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage")
    Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
    Link: https://patch.msgid.link/20241113103309.761031-1-zhenglifeng1@huawei.com
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae703f8ff083c5267af30d6c8cf096d562623b3b
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Tue Nov 12 09:39:51 2024 +0800

    hwmon: (nct6775-core) Fix overflows seen when writing limit attributes
    
    [ Upstream commit 57ee12b6c514146c19b6a159013b48727a012960 ]
    
    DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large
    number such as 18446744073709551615 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    
    Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
    Fixes: c3963bc0a0cf ("hwmon: (nct6775) Split core and platform driver")
    Message-ID: <7d5084cea33f7c0fd0578c59adfff71f93de94d9.1731375425.git.xiaopei01@kylinos.cn>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9666f48958d04c0fe9ae71c15ad87ce1d6667cf
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Sun Aug 18 11:18:17 2024 +0300

    doc: rcu: update printed dynticks counter bits
    
    [ Upstream commit 4a09e358922381f9b258e863bcd9c910584203b9 ]
    
    The stall warning prints 16 bits since commit 171476775d32
    ("context_tracking: Convert state to atomic_t").
    
    Fixes: 171476775d32 ("context_tracking: Convert state to atomic_t")
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Reviewed-by: "Paul E. McKenney" <paulmck@kernel.org>
    Signed-off-by: Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04dcf1ce3bbafd3e917bcfe6dc09ac7d1f8628ef
Author: Li Huafei <lihuafei1@huawei.com>
Date:   Thu Oct 31 19:27:55 2024 +0800

    crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()
    
    [ Upstream commit a10549fcce2913be7dc581562ffd8ea35653853e ]
    
    The commit 320406cb60b6 ("crypto: inside-secure - Replace generic aes
    with libaes") replaced crypto_alloc_cipher() with kmalloc(), but did not
    modify the handling of the return value. When kmalloc() returns NULL,
    PTR_ERR_OR_ZERO(NULL) returns 0, but in fact, the memory allocation has
    failed, and -ENOMEM should be returned.
    
    Fixes: 320406cb60b6 ("crypto: inside-secure - Replace generic aes with libaes")
    Signed-off-by: Li Huafei <lihuafei1@huawei.com>
    Acked-by: Antoine Tenart <atenart@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a80e710bbc088a2511c159ee4d910456c5f0832
Author: Orange Kao <orange@aiven.io>
Date:   Mon Nov 4 12:40:52 2024 +0000

    EDAC/igen6: Avoid segmentation fault on module unload
    
    [ Upstream commit fefaae90398d38a1100ccd73b46ab55ff4610fba ]
    
    The segmentation fault happens because:
    
    During modprobe:
    1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()
    2. In igen6_register_mci(), mci->pvt_info will point to
       &igen6_pvt->imc[mc]
    
    During rmmod:
    1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)
    2. In igen6_remove(), it will kfree(igen6_pvt);
    
    Fix this issue by setting mci->pvt_info to NULL to avoid the double
    kfree.
    
    Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219360
    Signed-off-by: Orange Kao <orange@aiven.io>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20241104124237.124109-2-orange@aiven.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67c3ca63d4e0dd41c8aadd199820cc23ef68113b
Author: Weili Qian <qianweili@huawei.com>
Date:   Sat Oct 26 19:44:29 2024 +0800

    crypto: hisilicon/qm - disable same error report before resetting
    
    [ Upstream commit c418ba6baca3ae10ffaf47b0803d2a9e6bf1af96 ]
    
    If an error indicating that the device needs to be reset is reported,
    disable the error reporting before device reset is complete,
    enable the error reporting after the reset is complete to prevent
    the same error from being reported repeatedly.
    
    Fixes: eaebf4c3b103 ("crypto: hisilicon - Unify hardware error init/uninit into QM")
    Signed-off-by: Weili Qian <qianweili@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea88b83f5e8afeaebbabc6f9e2724532f1799b46
Author: Everest K.C <everestkc@everestkc.com.np>
Date:   Fri Oct 18 10:23:10 2024 -0600

    crypto: cavium - Fix the if condition to exit loop after timeout
    
    [ Upstream commit 53d91ca76b6c426c546542a44c78507b42008c9e ]
    
    The while loop breaks in the first run because of incorrect
    if condition. It also causes the statements after the if to
    appear dead.
    Fix this by changing the condition from if(timeout--) to
    if(!timeout--).
    
    This bug was reported by Coverity Scan.
    Report:
    CID 1600859: (#1 of 1): Logically dead code (DEADCODE)
    dead_error_line: Execution cannot reach this statement: udelay(30UL);
    
    Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine")
    Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92834692a539b5b7f409e467a14667d64713b732
Author: Yi Yang <yiyang13@huawei.com>
Date:   Tue Oct 15 02:09:35 2024 +0000

    crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
    
    [ Upstream commit 662f2f13e66d3883b9238b0b96b17886179e60e2 ]
    
    Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for
    PADATA_RESET"), the pcrypt encryption and decryption operations return
    -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is
    generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns
    -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.
    Fix this issue by calling crypto layer directly without parallelization
    in that case.
    
    Fixes: 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ad60df36fa9857498f8c38dd354cbaade969cc7
Author: Priyanka Singh <priyanka.singh@nxp.com>
Date:   Wed Oct 16 16:31:11 2024 -0400

    EDAC/fsl_ddr: Fix bad bit shift operations
    
    [ Upstream commit 9ec22ac4fe766c6abba845290d5139a3fbe0153b ]
    
    Fix undefined behavior caused by left-shifting a negative value in the
    expression:
    
        cap_high ^ (1 << (bad_data_bit - 32))
    
    The variable bad_data_bit ranges from 0 to 63. When it is less than 32,
    bad_data_bit - 32 becomes negative, and left-shifting by a negative
    value in C is undefined behavior.
    
    Fix this by combining cap_high and cap_low into a 64-bit variable.
    
      [ bp: Massage commit message, simplify error bits handling. ]
    
    Fixes: ea2eb9a8b620 ("EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx")
    Signed-off-by: Priyanka Singh <priyanka.singh@nxp.com>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20241016-imx95_edac-v3-3-86ae6fc2756a@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f17f863256ff8741bf27d8d9fe3669c8b4fc41d9
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Oct 4 21:05:49 2024 +0200

    thermal: core: Initialize thermal zones before registering them
    
    [ Upstream commit 662f920f7e390db5d1a6792a2b0ffa59b6c962fc ]
    
    Since user space can start interacting with a new thermal zone as soon
    as device_register() called by thermal_zone_device_register_with_trips()
    returns, it is better to initialize the thermal zone before calling
    device_register() on it.
    
    Fixes: d0df264fbd3c ("thermal/core: Remove pointless thermal_zone_device_reset() function")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://patch.msgid.link/3336146.44csPzL39Z@rjwysocki.net
    Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8aaa74fd4ace57319863a7f6834369645f328661
Author: Ahsan Atta <ahsan.atta@intel.com>
Date:   Mon Oct 7 14:42:40 2024 +0100

    crypto: qat - remove faulty arbiter config reset
    
    [ Upstream commit 70199359902f1c7187dcb28a1be679a7081de7cc ]
    
    Resetting the service arbiter config can cause potential issues
    related to response ordering and ring flow control check in the
    event of AER or device hang. This is because it results in changing
    the default response ring size from 32 bytes to 16 bytes. The service
    arbiter config reset also disables response ring flow control check.
    Thus, by removing this reset we can prevent the service arbiter from
    being configured inappropriately, which leads to undesired device
    behaviour in the event of errors.
    
    Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator")
    Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 578ca89b04680145d41011e7cec8806fefbb59e7
Author: David Thompson <davthompson@nvidia.com>
Date:   Mon Sep 30 11:10:56 2024 -0400

    EDAC/bluefield: Fix potential integer overflow
    
    [ Upstream commit 1fe774a93b46bb029b8f6fa9d1f25affa53f06c6 ]
    
    The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx
    left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as
    32-bits wide the left-shift operation truncates the upper 16 bits of
    information during the calculation of the SMC argument.
    
    The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any
    potential integer overflow, i.e. loss of data from upper 16 bits.
    
    Fixes: 82413e562ea6 ("EDAC, mellanox: Add ECC support for BlueField DDR4")
    Signed-off-by: David Thompson <davthompson@nvidia.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Shravan Kumar Ramani <shravankr@nvidia.com>
    Link: https://lore.kernel.org/r/20240930151056.10158-1-davthompson@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5fbc57cecd27c4a9fd6515cfde18f16eb8c8503
Author: Yuan Can <yuancan@huawei.com>
Date:   Tue Oct 15 21:13:44 2024 +0800

    firmware: google: Unregister driver_info on failure
    
    [ Upstream commit 32b0901e141f6d4cf49d820b53eb09b88b1f72f7 ]
    
    When platform_device_register_full() returns error, the gsmi_init() returns
    without unregister gsmi_driver_info, fix by add missing
    platform_driver_unregister() when platform_device_register_full() failed.
    
    Fixes: 8942b2d5094b ("gsmi: Add GSMI commands to log S0ix info")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Link: https://lore.kernel.org/r/20241015131344.20272-1-yuancan@huawei.com
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66eddb8dcb61065c53098510165f14b54232bcc2
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Sep 15 12:22:12 2024 +0200

    crypto: caam - Fix the pointer passed to caam_qi_shutdown()
    
    [ Upstream commit ad980b04f51f7fb503530bd1cb328ba5e75a250e ]
    
    The type of the last parameter given to devm_add_action_or_reset() is
    "struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to
    "struct device *".
    
    Pass the correct parameter to devm_add_action_or_reset() so that the
    resources are released as expected.
    
    Fixes: f414de2e2fff ("crypto: caam - use devres to de-initialize QI")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58998a4595f4d7bf6c37cb135bfa6f6f89561337
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Nov 13 16:20:42 2024 +0100

    virtio_blk: reverse request order in virtio_queue_rqs
    
    [ Upstream commit 7f212e997edbb7a2cb85cef2ac14265dfaf88717 ]
    
    blk_mq_flush_plug_list submits requests in the reverse order that they
    were submitted, which leads to a rather suboptimal I/O pattern
    especially in rotational devices. Fix this by rewriting virtio_queue_rqs
    so that it always pops the requests from the passed in request list, and
    then adds them to the head of a local submit list. This actually
    simplifies the code a bit as it removes the complicated list splicing,
    at the cost of extra updates of the rq_next pointer. As that should be
    cache hot anyway it should be an easy price to pay.
    
    Fixes: 0e9911fa768f ("virtio-blk: support mq_ops->queue_rqs()")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20241113152050.157179-3-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 995457cd2a43fff98e1a83a10b0f61f2a1a4606e
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Nov 13 16:20:41 2024 +0100

    nvme-pci: reverse request order in nvme_queue_rqs
    
    [ Upstream commit beadf0088501d9dcf2454b05d90d5d31ea3ba55f ]
    
    blk_mq_flush_plug_list submits requests in the reverse order that they
    were submitted, which leads to a rather suboptimal I/O pattern especially
    in rotational devices.  Fix this by rewriting nvme_queue_rqs so that it
    always pops the requests from the passed in request list, and then adds
    them to the head of a local submit list.  This actually simplifies the
    code a bit as it removes the complicated list splicing, at the cost of
    extra updates of the rq_next pointer.  As that should be cache hot
    anyway it should be an easy price to pay.
    
    Fixes: d62cbcf62f2f ("nvme: add support for mq_ops->queue_rqs()")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20241113152050.157179-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d7bda75e1a6239db053c73acde17ca146317824
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Thu Nov 7 08:41:09 2024 -0300

    hfsplus: don't query the device logical block size multiple times
    
    [ Upstream commit 1c82587cb57687de3f18ab4b98a8850c789bedcf ]
    
    Devices block sizes may change. One of these cases is a loop device by
    using ioctl LOOP_SET_BLOCK_SIZE.
    
    While this may cause other issues like IO being rejected, in the case of
    hfsplus, it will allocate a block by using that size and potentially write
    out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
    latter function reads a different io_size.
    
    Using a new min_io_size initally set to sb_min_blocksize works for the
    purposes of the original fix, since it will be set to the max between
    HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the
    max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not
    initialized.
    
    Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024
    and 4096.
    
    The produced KASAN report before the fix looks like this:
    
    [  419.944641] ==================================================================
    [  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a
    [  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678
    [  419.947612]
    [  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84
    [  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    [  419.950035] Call Trace:
    [  419.950384]  <TASK>
    [  419.950676]  dump_stack_lvl+0x57/0x78
    [  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a
    [  419.951830]  print_report+0x14c/0x49e
    [  419.952361]  ? __virt_addr_valid+0x267/0x278
    [  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d
    [  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a
    [  419.954231]  kasan_report+0x89/0xb0
    [  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a
    [  419.955367]  hfsplus_read_wrapper+0x659/0xa0a
    [  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10
    [  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9
    [  419.957214]  ? _raw_spin_unlock+0x1a/0x2e
    [  419.957772]  hfsplus_fill_super+0x348/0x1590
    [  419.958355]  ? hlock_class+0x4c/0x109
    [  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10
    [  419.959499]  ? __pfx_string+0x10/0x10
    [  419.960006]  ? lock_acquire+0x3e2/0x454
    [  419.960532]  ? bdev_name.constprop.0+0xce/0x243
    [  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10
    [  419.961799]  ? pointer+0x3f0/0x62f
    [  419.962277]  ? __pfx_pointer+0x10/0x10
    [  419.962761]  ? vsnprintf+0x6c4/0xfba
    [  419.963178]  ? __pfx_vsnprintf+0x10/0x10
    [  419.963621]  ? setup_bdev_super+0x376/0x3b3
    [  419.964029]  ? snprintf+0x9d/0xd2
    [  419.964344]  ? __pfx_snprintf+0x10/0x10
    [  419.964675]  ? lock_acquired+0x45c/0x5e9
    [  419.965016]  ? set_blocksize+0x139/0x1c1
    [  419.965381]  ? sb_set_blocksize+0x6d/0xae
    [  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10
    [  419.966179]  mount_bdev+0x12f/0x1bf
    [  419.966512]  ? __pfx_mount_bdev+0x10/0x10
    [  419.966886]  ? vfs_parse_fs_string+0xce/0x111
    [  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10
    [  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10
    [  419.968073]  legacy_get_tree+0x104/0x178
    [  419.968414]  vfs_get_tree+0x86/0x296
    [  419.968751]  path_mount+0xba3/0xd0b
    [  419.969157]  ? __pfx_path_mount+0x10/0x10
    [  419.969594]  ? kmem_cache_free+0x1e2/0x260
    [  419.970311]  do_mount+0x99/0xe0
    [  419.970630]  ? __pfx_do_mount+0x10/0x10
    [  419.971008]  __do_sys_mount+0x199/0x1c9
    [  419.971397]  do_syscall_64+0xd0/0x135
    [  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  419.972233] RIP: 0033:0x7c3cb812972e
    [  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48
    [  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
    [  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e
    [  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: 00007ffe306325d0
    [  419.976363] RBP: 00007ffe30632720 R08: 00007ffe30632610 R09: 0000000000000000
    [  419.977034] R10: 0000000000200008 R11: 0000000000000286 R12: 0000000000000000
    [  419.977713] R13: 00007ffe306328e8 R14: 00005a0eb298bc68 R15: 00007c3cb8356000
    [  419.978375]  </TASK>
    [  419.978589]
    
    Fixes: 6596528e391a ("hfsplus: ensure bio requests are not smaller than the hardware sectors")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Link: https://lore.kernel.org/r/20241107114109.839253-1-cascardo@igalia.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1a52470f107a5b20ff20013471586b6792d07aa
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Nov 11 22:45:52 2024 +0900

    s390/syscalls: Avoid creation of arch/arch/ directory
    
    [ Upstream commit 0708967e2d56e370231fd07defa0d69f9ad125e8 ]
    
    Building the kernel with ARCH=s390 creates a weird arch/arch/ directory.
    
      $ find arch/arch
      arch/arch
      arch/arch/s390
      arch/arch/s390/include
      arch/arch/s390/include/generated
      arch/arch/s390/include/generated/asm
      arch/arch/s390/include/generated/uapi
      arch/arch/s390/include/generated/uapi/asm
    
    The root cause is 'targets' in arch/s390/kernel/syscalls/Makefile,
    where the relative path is incorrect.
    
    Strictly speaking, 'targets' was not necessary in the first place
    because this Makefile uses 'filechk' instead of 'if_changed'.
    
    However, this commit keeps it, as it will be useful when converting
    'filechk' to 'if_changed' later.
    
    Fixes: 5c75824d915e ("s390/syscalls: add Makefile to generate system call header files")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/r/20241111134603.2063226-1-masahiroy@kernel.org
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2cd22baf749d129ae254fb02da45d65cc218a574
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Nov 4 07:26:30 2024 +0100

    block: fix bio_split_rw_at to take zone_write_granularity into account
    
    [ Upstream commit 7ecd2cd4fae3e8410c0a6620f3a83dcdbb254f02 ]
    
    Otherwise it can create unaligned writes on zoned devices.
    
    Fixes: a805a4fa4fa3 ("block: introduce zone_write_granularity limit")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20241104062647.91160-3-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddab02607eed9e415dc62fde421d4329e5345315
Author: Zizhi Wo <wozizhi@huawei.com>
Date:   Thu Nov 7 19:06:49 2024 +0800

    netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING
    
    [ Upstream commit 22f9400a6f3560629478e0a64247b8fcc811a24d ]
    
    In fscache_create_volume(), there is a missing memory barrier between the
    bit-clearing operation and the wake-up operation. This may cause a
    situation where, after a wake-up, the bit-clearing operation hasn't been
    detected yet, leading to an indefinite wait. The triggering process is as
    follows:
    
      [cookie1]                [cookie2]                  [volume_work]
    fscache_perform_lookup
      fscache_create_volume
                            fscache_perform_lookup
                              fscache_create_volume
                                                    fscache_create_volume_work
                                                      cachefiles_acquire_volume
                                                      clear_and_wake_up_bit
        test_and_set_bit
                                test_and_set_bit
                                  goto maybe_wait
          goto no_wait
    
    In the above process, cookie1 and cookie2 has the same volume. When cookie1
    enters the -no_wait- process, it will clear the bit and wake up the waiting
    process. If a barrier is missing, it may cause cookie2 to remain in the
    -wait- process indefinitely.
    
    In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in
    fscache_create_volume_work()"), barriers were added to similar operations
    in fscache_create_volume_work(), but fscache_create_volume() was missed.
    
    By combining the clear and wake operations into clear_and_wake_up_bit() to
    fix this issue.
    
    Fixes: bfa22da3ed65 ("fscache: Provide and use cache methods to lookup/create/free a volume")
    Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
    Link: https://lore.kernel.org/r/20241107110649.3980193-6-wozizhi@huawei.com
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 679d7276d4375df4b70b9d0cfe03230997e4f83f
Author: Zizhi Wo <wozizhi@huawei.com>
Date:   Thu Nov 7 19:06:46 2024 +0800

    cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()
    
    [ Upstream commit 56f4856b425a30e1d8b3e41e6cde8bfba90ba5f8 ]
    
    In the erofs on-demand loading scenario, read and write operations are
    usually delivered through "off" and "len" contained in read req in user
    mode. Naturally, pwrite is used to specify a specific offset to complete
    write operations.
    
    However, if the write(not pwrite) syscall is called multiple times in the
    read-ahead scenario, we need to manually update ki_pos after each write
    operation to update file->f_pos.
    
    This step is currently missing from the cachefiles_ondemand_fd_write_iter
    function, added to address this issue.
    
    Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie")
    Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
    Link: https://lore.kernel.org/r/20241107110649.3980193-3-wozizhi@huawei.com
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c68110dee0a7d108069a916ebb82538edda834f4
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Tue Aug 27 13:12:39 2024 +0300

    acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()
    
    [ Upstream commit 1a9de2f6fda69d5f105dd8af776856a66abdaa64 ]
    
    In case of error in gtdt_parse_timer_block() invalid 'gtdt_frame'
    will be used in 'do {} while (i-- >= 0 && gtdt_frame--);' statement block
    because do{} block will be executed even if 'i == 0'.
    
    Adjust error handling procedure by replacing 'i-- >= 0' with 'i-- > 0'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Acked-by: Hanjun Guo <guohanjun@huawei.com>
    Acked-by: Sudeep Holla <sudeep.holla@arm.com>
    Acked-by: Aleksandr Mishin <amishin@t-argos.ru>
    Link: https://lore.kernel.org/r/20240827101239.22020-1-amishin@t-argos.ru
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bae56996ffcafb6d55be59e43e3f842234936ce1
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Nov 7 01:18:42 2024 +0900

    arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG
    
    [ Upstream commit 340fd66c856651d8c1d29f392dd26ad674d2db0e ]
    
    Commit be2881824ae9 ("arm64/build: Assert for unwanted sections")
    introduced an assertion to ensure that the .data.rel.ro section does
    not exist.
    
    However, this check does not work when CONFIG_LTO_CLANG is enabled,
    because .data.rel.ro matches the .data.[0-9a-zA-Z_]* pattern in the
    DATA_MAIN macro.
    
    Move the ASSERT() above the RW_DATA() line.
    
    Fixes: be2881824ae9 ("arm64/build: Assert for unwanted sections")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20241106161843.189927-1-masahiroy@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8627dde405d4e7139a5e18f862f145dbef1ed4d
Author: Daniel Palmer <daniel@0x0f.com>
Date:   Wed Nov 6 10:51:24 2024 +1100

    m68k: mvme147: Reinstate early console
    
    [ Upstream commit 077b33b9e2833ff25050d986178a2c4c4036cbac ]
    
    Commit a38eaa07a0ce ("m68k/mvme147: config.c - Remove unused
    functions"), removed the console functionality for the mvme147 instead
    of wiring it up to an early console.  Put the console write function
    back and wire it up like mvme16x does so it's possible to see Linux boot
    on this fine hardware once more.
    
    Fixes: a38eaa07a0ce ("m68k/mvme147: config.c - Remove unused functions")
    Signed-off-by: Daniel Palmer <daniel@0x0f.com>
    Co-developed-by: Finn Thain <fthain@linux-m68k.org>
    Signed-off-by: Finn Thain <fthain@linux-m68k.org>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/a82e8f0068a8722996a0ccfe666abb5e0a5c120d.1730850684.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 797cb79af128b39f33537b4bd50ca20777b8af82
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed Sep 13 16:08:25 2023 +0200

    m68k: mvme16x: Add and use "mvme16x.h"
    
    [ Upstream commit dcec33c1fc4ab63983d93ffb0d82b68fc5775b88 ]
    
    When building with W=1:
    
        arch/m68k/mvme16x/config.c:208:6: warning: no previous prototype for ‘mvme16x_cons_write’ [-Wmissing-prototypes]
          208 | void mvme16x_cons_write(struct console *co, const char *str, unsigned count)
              |      ^~~~~~~~~~~~~~~~~~
    
    Fix this by introducing a new header file "mvme16x.h" for holding the
    prototypes of functions implemented in arch/m68k/mvme16x/.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/6200cc3b26fad215c4524748af04692e38c5ecd2.1694613528.git.geert@linux-m68k.org
    Stable-dep-of: 077b33b9e283 ("m68k: mvme147: Reinstate early console")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cd327b45c7b42166ddf3090cdb7969620dc833f
Author: Daniel Palmer <daniel@0x0f.com>
Date:   Thu Oct 3 13:29:47 2024 +1000

    m68k: mvme147: Fix SCSI controller IRQ numbers
    
    [ Upstream commit 47bc874427382018fa2e3e982480e156271eee70 ]
    
    Sometime long ago the m68k IRQ code was refactored and the interrupt
    numbers for SCSI controller on this board ended up wrong, and it hasn't
    worked since.
    
    The PCC adds 0x40 to the vector for its interrupts so they end up in
    the user interrupt range. Hence, the kernel number should be the kernel
    offset for user interrupt range + the PCC interrupt number.
    
    Fixes: 200a3d352cd5 ("[PATCH] m68k: convert VME irq code")
    Signed-off-by: Daniel Palmer <daniel@0x0f.com>
    Reviewed-by: Finn Thain <fthain@linux-m68k.org>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/0e7636a21a0274eea35bfd5d874459d5078e97cc.1727926187.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb96d5cfa97a7363245b3dd523f475b04296d87b
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Nov 1 05:40:04 2024 +0100

    nvme-pci: fix freeing of the HMB descriptor table
    
    [ Upstream commit 3c2fb1ca8086eb139b2a551358137525ae8e0d7a ]
    
    The HMB descriptor table is sized to the maximum number of descriptors
    that could be used for a given device, but __nvme_alloc_host_mem could
    break out of the loop earlier on memory allocation failure and end up
    using less descriptors than planned for, which leads to an incorrect
    size passed to dma_free_coherent.
    
    In practice this was not showing up because the number of descriptors
    tends to be low and the dma coherent allocator always allocates and
    frees at least a page.
    
    Fixes: 87ad72a59a38 ("nvme-pci: implement host memory buffer support")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f892ddcf9f645380c358e73653cb0900f6bc9eb8
Author: David Disseldorp <ddiss@suse.de>
Date:   Wed Oct 30 03:55:10 2024 +0000

    initramfs: avoid filename buffer overrun
    
    [ Upstream commit e017671f534dd3f568db9e47b0583e853d2da9b5 ]
    
    The initramfs filename field is defined in
    Documentation/driver-api/early-userspace/buffer-format.rst as:
    
     37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
    ...
     55 ============= ================== =========================
     56 Field name    Field size         Meaning
     57 ============= ================== =========================
    ...
     70 c_namesize    8 bytes            Length of filename, including final \0
    
    When extracting an initramfs cpio archive, the kernel's do_name() path
    handler assumes a zero-terminated path at @collected, passing it
    directly to filp_open() / init_mkdir() / init_mknod().
    
    If a specially crafted cpio entry carries a non-zero-terminated filename
    and is followed by uninitialized memory, then a file may be created with
    trailing characters that represent the uninitialized memory. The ability
    to create an initramfs entry would imply already having full control of
    the system, so the buffer overrun shouldn't be considered a security
    vulnerability.
    
    Append the output of the following bash script to an existing initramfs
    and observe any created /initramfs_test_fname_overrunAA* path. E.g.
      ./reproducer.sh | gzip >> /myinitramfs
    
    It's easiest to observe non-zero uninitialized memory when the output is
    gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
    rather than the initrd_start+initrd_size block.
    
    ---- reproducer.sh ----
    nilchar="A"     # change to "\0" to properly zero terminate / pad
    magic="070701"
    ino=1
    mode=$(( 0100777 ))
    uid=0
    gid=0
    nlink=1
    mtime=1
    filesize=0
    devmajor=0
    devminor=1
    rdevmajor=0
    rdevminor=0
    csum=0
    fname="initramfs_test_fname_overrun"
    namelen=$(( ${#fname} + 1 ))    # plus one to account for terminator
    
    printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
            $magic $ino $mode $uid $gid $nlink $mtime $filesize \
            $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname
    
    termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))
    printf "%.s${nilchar}" $(seq 1 $termpadlen)
    ---- reproducer.sh ----
    
    Symlink filename fields handled in do_symlink() won't overrun past the
    data segment, due to the explicit zero-termination of the symlink
    target.
    
    Fix filename buffer overrun by aborting the initramfs FSM if any cpio
    entry doesn't carry a zero-terminator at the expected (name_len - 1)
    offset.
    
    Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Link: https://lore.kernel.org/r/20241030035509.20194-2-ddiss@suse.de
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7961d460eceb1f35d0a9bcf6a4f8630869d6b236
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sat Oct 12 12:12:14 2024 +0200

    mips: asm: fix warning when disabling MIPS_FP_SUPPORT
    
    [ Upstream commit da09935975c8f8c90d6f57be2422dee5557206cd ]
    
    When MIPS_FP_SUPPORT is disabled, __sanitize_fcr31() is defined as
    nothing, which triggers a gcc warning:
    
        In file included from kernel/sched/core.c:79:
        kernel/sched/core.c: In function 'context_switch':
        ./arch/mips/include/asm/switch_to.h:114:39: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
          114 |                 __sanitize_fcr31(next);                                 \
              |                                       ^
        kernel/sched/core.c:5316:9: note: in expansion of macro 'switch_to'
         5316 |         switch_to(prev, next, prev);
              |         ^~~~~~~~~
    
    Fix this by providing an empty body for __sanitize_fcr31() like one is
    defined for __mips_mt_fpaff_switch_to().
    
    Fixes: 36a498035bd2 ("MIPS: Avoid FCSR sanitization when CONFIG_MIPS_FP_SUPPORT=n")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfc2eb29016f2fd9713654f0c20fe5c440bbc33d
Author: Jan Kara <jack@suse.cz>
Date:   Sat Oct 5 00:15:56 2024 +0200

    ext4: avoid remount errors with 'abort' mount option
    
    [ Upstream commit 76486b104168ae59703190566e372badf433314b ]
    
    When we remount filesystem with 'abort' mount option while changing
    other mount options as well (as is LTP test doing), we can return error
    from the system call after commit d3476f3dad4a ("ext4: don't set
    SB_RDONLY after filesystem errors") because the application of mount
    option changes detects shutdown filesystem and refuses to do anything.
    The behavior of application of other mount options in presence of
    'abort' mount option is currently rather arbitary as some mount option
    changes are handled before 'abort' and some after it.
    
    Move aborting of the filesystem to the end of remount handling so all
    requested changes are properly applied before the filesystem is shutdown
    to have a reasonably consistent behavior.
    
    Fixes: d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors")
    Reported-by: Jan Stancek <jstancek@redhat.com>
    Link: https://lore.kernel.org/all/Zvp6L+oFnfASaoHl@t14s
    Signed-off-by: Jan Kara <jack@suse.cz>
    Tested-by: Jan Stancek <jstancek@redhat.com>
    Link: https://patch.msgid.link/20241004221556.19222-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8dad6db0ed64f7de05a7f62e78e7d4f8bf2c8b3
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 16 18:50:50 2023 +0200

    ext4: make 'abort' mount option handling standard
    
    [ Upstream commit 22b8d707b07e6e06f50fe1d9ca8756e1f894eb0d ]
    
    'abort' mount option is the only mount option that has special handling
    and sets a bit in sbi->s_mount_flags. There is not strong reason for
    that so just simplify the code and make 'abort' set a bit in
    sbi->s_mount_opt2 as any other mount option. This simplifies the code
    and will allow us to drop EXT4_MF_FS_ABORTED completely in the following
    patch.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230616165109.21695-4-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 76486b104168 ("ext4: avoid remount errors with 'abort' mount option")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 259bf925583ec9e3781df778cadf00594095090d
Author: Yang Erkun <yangerkun@huawei.com>
Date:   Wed Oct 30 11:49:14 2024 +0800

    brd: defer automatic disk creation until module initialization succeeds
    
    [ Upstream commit 826cc42adf44930a633d11a5993676d85ddb0842 ]
    
    My colleague Wupeng found the following problems during fault injection:
    
    BUG: unable to handle page fault for address: fffffbfff809d073
    PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0
    Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
    CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.16.1-2.fc37 04/01/2014
    RIP: 0010:__asan_load8+0x4c/0xa0
    ...
    Call Trace:
     <TASK>
     blkdev_put_whole+0x41/0x70
     bdev_release+0x1a3/0x250
     blkdev_release+0x11/0x20
     __fput+0x1d7/0x4a0
     task_work_run+0xfc/0x180
     syscall_exit_to_user_mode+0x1de/0x1f0
     do_syscall_64+0x6b/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    loop_init() is calling loop_add() after __register_blkdev() succeeds and
    is ignoring disk_add() failure from loop_add(), for loop_add() failure
    is not fatal and successfully created disks are already visible to
    bdev_open().
    
    brd_init() is currently calling brd_alloc() before __register_blkdev()
    succeeds and is releasing successfully created disks when brd_init()
    returns an error. This can cause UAF for the latter two case:
    
    case 1:
        T1:
    modprobe brd
      brd_init
        brd_alloc(0) // success
          add_disk
            disk_scan_partitions
              bdev_file_open_by_dev // alloc file
              fput // won't free until back to userspace
        brd_alloc(1) // failed since mem alloc error inject
      // error path for modprobe will release code segment
      // back to userspace
      __fput
        blkdev_release
          bdev_release
            blkdev_put_whole
              bdev->bd_disk->fops->release // fops is freed now, UAF!
    
    case 2:
        T1:                            T2:
    modprobe brd
      brd_init
        brd_alloc(0) // success
                                       open(/dev/ram0)
        brd_alloc(1) // fail
      // error path for modprobe
    
                                       close(/dev/ram0)
                                       ...
                                       /* UAF! */
                                       bdev->bd_disk->fops->release
    
    Fix this problem by following what loop_init() does. Besides,
    reintroduce brd_devices_mutex to help serialize modifications to
    brd_list.
    
    Fixes: 7f9b348cb5e9 ("brd: convert to blk_alloc_disk/blk_cleanup_disk")
    Reported-by: Wupeng Ma <mawupeng1@huawei.com>
    Signed-off-by: Yang Erkun <yangerkun@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20241030034914.907829-1-yangerkun@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2185802447683c98c3e5d621b310991f84def998
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Mon Sep 23 22:16:43 2024 +0200

    s390/cio: Do not unregister the subchannel based on DNV
    
    [ Upstream commit 8c58a229688ce3a097b3b1a2efe1b4f5508c2123 ]
    
    Starting with commit 2297791c92d0 ("s390/cio: dont unregister
    subchannel from child-drivers"), CIO does not unregister subchannels
    when the attached device is invalid or unavailable. Instead, it
    allows subchannels to exist without a connected device. However, if
    the DNV value is 0, such as, when all the CHPIDs of a subchannel are
    configured in standby state, the subchannel is unregistered, which
    contradicts the current subchannel specification.
    
    Update the logic so that subchannels are not unregistered based
    on the DNV value. Also update the SCHIB information even if the
    DNV bit is zero.
    
    Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64a56ca76bd90867e1ee0fee87c10e01021c5cc4
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri Aug 16 16:32:51 2024 +0100

    kselftest/arm64: mte: fix printf type warnings about longs
    
    [ Upstream commit 96dddb7b9406259baace9a1831e8da155311be6f ]
    
    When checking MTE tags, we print some diagnostic messages when the tests
    fail. Some variables uses there are "longs", however we only use "%x"
    for the format specifier.
    
    Update the format specifiers to "%lx", to match the variable types they
    are supposed to print.
    
    Fixes: f3b2a26ca78d ("kselftest/arm64: Verify mte tag inclusion via prctl")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240816153251.2833702-9-andre.przywara@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59f99fa254cf55236fa680bc3322aa835970d6c7
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri Aug 16 16:32:49 2024 +0100

    kselftest/arm64: mte: fix printf type warnings about __u64
    
    [ Upstream commit 7e893dc81de3e342156389ea0b83ec7d07f25281 ]
    
    When printing the signal context's PC, we use a "%lx" format specifier,
    which matches the common userland (glibc's) definition of uint64_t as an
    "unsigned long". However the structure in question is defined in a
    kernel uapi header, which uses a self defined __u64 type, and the arm64
    kernel headers define this using "int-ll64.h", so it becomes an
    "unsigned long long". This mismatch leads to the usual compiler warning.
    
    The common fix would be to use "PRIx64", but because this is defined by
    the userland's toolchain libc headers, it wouldn't match as well. Since
    we know the exact type of __u64, just use "%llx" here instead, to silence
    this warning.
    
    This also fixes a more severe typo: "$lx" is not a valid format
    specifier.
    
    Fixes: 191e678bdc9b ("kselftest/arm64: Log unexpected asynchronous MTE faults")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240816153251.2833702-7-andre.przywara@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cefad6b772c86b7463b35a4eb57021f18ea7f251
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Fri Oct 27 14:24:16 2023 +0200

    x86/barrier: Do not serialize MSR accesses on AMD
    
    commit 04c3024560d3a14acd18d0a51a1d0a89d29b7eb5 upstream.
    
    AMD does not have the requirement for a synchronization barrier when
    acccessing a certain group of MSRs. Do not incur that unnecessary
    penalty there.
    
    There will be a CPUID bit which explicitly states that a MFENCE is not
    needed. Once that bit is added to the APM, this will be extended with
    it.
    
    While at it, move to processor.h to avoid include hell. Untangling that
    file properly is a matter for another day.
    
    Some notes on the performance aspect of why this is relevant, courtesy
    of Kishon VijayAbraham <Kishon.VijayAbraham@amd.com>:
    
    On a AMD Zen4 system with 96 cores, a modified ipi-bench[1] on a VM
    shows x2AVIC IPI rate is 3% to 4% lower than AVIC IPI rate. The
    ipi-bench is modified so that the IPIs are sent between two vCPUs in the
    same CCX. This also requires to pin the vCPU to a physical core to
    prevent any latencies. This simulates the use case of pinning vCPUs to
    the thread of a single CCX to avoid interrupt IPI latency.
    
    In order to avoid run-to-run variance (for both x2AVIC and AVIC), the
    below configurations are done:
    
      1) Disable Power States in BIOS (to prevent the system from going to
         lower power state)
    
      2) Run the system at fixed frequency 2500MHz (to prevent the system
         from increasing the frequency when the load is more)
    
    With the above configuration:
    
    *) Performance measured using ipi-bench for AVIC:
      Average Latency:  1124.98ns [Time to send IPI from one vCPU to another vCPU]
    
      Cumulative throughput: 42.6759M/s [Total number of IPIs sent in a second from
                                         48 vCPUs simultaneously]
    
    *) Performance measured using ipi-bench for x2AVIC:
      Average Latency:  1172.42ns [Time to send IPI from one vCPU to another vCPU]
    
      Cumulative throughput: 40.9432M/s [Total number of IPIs sent in a second from
                                         48 vCPUs simultaneously]
    
    From above, x2AVIC latency is ~4% more than AVIC. However, the expectation is
    x2AVIC performance to be better or equivalent to AVIC. Upon analyzing
    the perf captures, it is observed significant time is spent in
    weak_wrmsr_fence() invoked by x2apic_send_IPI().
    
    With the fix to skip weak_wrmsr_fence()
    
    *) Performance measured using ipi-bench for x2AVIC:
      Average Latency:  1117.44ns [Time to send IPI from one vCPU to another vCPU]
    
      Cumulative throughput: 42.9608M/s [Total number of IPIs sent in a second from
                                         48 vCPUs simultaneously]
    
    Comparing the performance of x2AVIC with and without the fix, it can be seen
    the performance improves by ~4%.
    
    Performance captured using an unmodified ipi-bench using the 'mesh-ipi' option
    with and without weak_wrmsr_fence() on a Zen4 system also showed significant
    performance improvement without weak_wrmsr_fence(). The 'mesh-ipi' option ignores
    CCX or CCD and just picks random vCPU.
    
      Average throughput (10 iterations) with weak_wrmsr_fence(),
            Cumulative throughput: 4933374 IPI/s
    
      Average throughput (10 iterations) without weak_wrmsr_fence(),
            Cumulative throughput: 6355156 IPI/s
    
    [1] https://github.com/bytedance/kvm-utils/tree/master/microbenchmark/ipi-bench
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20230622095212.20940-1-bp@alien8.de
    Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a4159138e718db6199f0abf376ad52f726dcc5c
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Mon Nov 25 16:04:01 2024 +0800

    fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name
    
    [ Upstream commit 7f7b850689ac06a62befe26e1fd1806799e7f152 ]
    
    It's observed that a crash occurs during hot-remove a memory device,
    in which user is accessing the hugetlb. See calltrace as following:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790
    Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s
    mirror dm_region_hash dm_log dm_mod
    CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    RIP: 0010:do_user_addr_fault+0x2a0/0x790
    Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41
    RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046
    RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658
    R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000
    FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ? __warn+0x8d/0x190
     ? do_user_addr_fault+0x2a0/0x790
     ? report_bug+0x1c3/0x1d0
     ? handle_bug+0x3c/0x70
     ? exc_invalid_op+0x14/0x70
     ? asm_exc_invalid_op+0x16/0x20
     ? do_user_addr_fault+0x2a0/0x790
     ? exc_page_fault+0x31/0x200
     exc_page_fault+0x68/0x200
    <...snip...>
    BUG: unable to handle page fault for address: 0000000000001000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
     Oops: Oops: 0000 [#1] PREEMPT SMP PTI
     ---[ end trace 0000000000000000 ]---
     BUG: unable to handle page fault for address: 0000000000001000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
     Oops: Oops: 0000 [#1] PREEMPT SMP PTI
     CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
     RIP: 0010:dentry_name+0x1f4/0x440
    <...snip...>
    ? dentry_name+0x2fa/0x440
    vsnprintf+0x1f3/0x4f0
    vprintk_store+0x23a/0x540
    vprintk_emit+0x6d/0x330
    _printk+0x58/0x80
    dump_mapping+0x10b/0x1a0
    ? __pfx_free_object_rcu+0x10/0x10
    __dump_page+0x26b/0x3e0
    ? vprintk_emit+0xe0/0x330
    ? _printk+0x58/0x80
    ? dump_page+0x17/0x50
    dump_page+0x17/0x50
    do_migrate_range+0x2f7/0x7f0
    ? do_migrate_range+0x42/0x7f0
    ? offline_pages+0x2f4/0x8c0
    offline_pages+0x60a/0x8c0
    memory_subsys_offline+0x9f/0x1c0
    ? lockdep_hardirqs_on+0x77/0x100
    ? _raw_spin_unlock_irqrestore+0x38/0x60
    device_offline+0xe3/0x110
    state_store+0x6e/0xc0
    kernfs_fop_write_iter+0x143/0x200
    vfs_write+0x39f/0x560
    ksys_write+0x65/0xf0
    do_syscall_64+0x62/0x130
    
    Previously, some sanity check have been done in dump_mapping() before
    the print facility parsing '%pd' though, it's still possible to run into
    an invalid dentry.d_name.name.
    
    Since dump_mapping() only needs to dump the filename only, retrieve it
    by itself in a safer way to prevent an unnecessary crash.
    
    Note that either retrieving the filename with '%pd' or
    strncpy_from_kernel_nofault(), the filename could be unreliable.
    
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Link: https://lore.kernel.org/r/20240826055503.1522320-1-lizhijian@fujitsu.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [Xiangyu: Bp to fix CVE: CVE-2024-49934, modified strscpy step due to 6.1/6.6 need pass
    the max len to strscpy]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9be768f08b16f020da376538b08463ac3a2ce8cd
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Nov 26 17:36:04 2024 +0800

    drm/amd/display: Initialize denominators' default to 1
    
    [ Upstream commit b995c0a6de6c74656a0c39cd57a0626351b13e3c ]
    
    [WHAT & HOW]
    Variables used as denominators and maybe not assigned to other values,
    should not be 0. Change their default to 1 so they are never 0.
    
    This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [Xiangyu: Bp to fix CVE: CVE-2024-49899
    Discard the dml2_core/dml2_core_shared.c due to this file no exists]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b04650b5a9990cf5c0de480e62c68199f1396a04
Author: Chih-Kang Chang <gary.chang@realtek.com>
Date:   Mon Nov 25 14:25:49 2024 +0800

    wifi: rtw89: avoid to add interface to list twice when SER
    
    [ Upstream commit 7dd5d2514a8ea58f12096e888b0bd050d7eae20a ]
    
    If SER L2 occurs during the WoWLAN resume flow, the add interface flow
    is triggered by ieee80211_reconfig(). However, due to
    rtw89_wow_resume() return failure, it will cause the add interface flow
    to be executed again, resulting in a double add list and causing a kernel
    panic. Therefore, we have added a check to prevent double adding of the
    list.
    
    list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.
    ------------[ cut here ]------------
    kernel BUG at lib/list_debug.c:37!
    invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7
    Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021
    Workqueue: events_freezable ieee80211_restart_work [mac80211]
    RIP: 0010:__list_add_valid_or_report+0x5e/0xb0
    Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12
    RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246
    RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900
    RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001
    RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0
    R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060
    R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010
    FS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0
    Call Trace:
     <TASK>
     ? __die_body+0x1f/0x70
     ? die+0x3d/0x60
     ? do_trap+0xa4/0x110
     ? __list_add_valid_or_report+0x5e/0xb0
     ? do_error_trap+0x6d/0x90
     ? __list_add_valid_or_report+0x5e/0xb0
     ? handle_invalid_op+0x30/0x40
     ? __list_add_valid_or_report+0x5e/0xb0
     ? exc_invalid_op+0x3c/0x50
     ? asm_exc_invalid_op+0x16/0x20
     ? __list_add_valid_or_report+0x5e/0xb0
     rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]
     drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
     ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
     ? finish_wait+0x3e/0x90
     ? synchronize_rcu_expedited+0x174/0x260
     ? sync_rcu_exp_done_unlocked+0x50/0x50
     ? wake_bit_function+0x40/0x40
     ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
     process_scheduled_works+0x1e5/0x480
     worker_thread+0xea/0x1e0
     kthread+0xdb/0x110
     ? move_linked_works+0x90/0x90
     ? kthread_associate_blkcg+0xa0/0xa0
     ret_from_fork+0x3b/0x50
     ? kthread_associate_blkcg+0xa0/0xa0
     ret_from_fork_asm+0x11/0x20
     </TASK>
    Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev
    gsmi: Log Shutdown Reason 0x03
    ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20240731070506.46100-4-pkshih@realtek.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aeb1293a788b85e1e58b28e79fb4ab731693afb0
Author: Dmitry Kandybka <d.kandybka@gmail.com>
Date:   Mon Nov 25 15:05:25 2024 +0100

    mptcp: fix possible integer overflow in mptcp_reset_tout_timer
    
    commit b169e76ebad22cbd055101ee5aa1a7bed0e66606 upstream.
    
    In 'mptcp_reset_tout_timer', promote 'probe_timestamp' to unsigned long
    to avoid possible integer overflow. Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
    Link: https://patch.msgid.link/20241107103657.1560536-1-d.kandybka@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflict in this version because commit d866ae9aaa43 ("mptcp: add a
      new sysctl for make after break timeout") is not in this version, and
      replaced TCP_TIMEWAIT_LEN in the expression. The fix can still be
      applied the same way: by forcing a cast to unsigned long for the first
      item. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a9c40c72097b583b23aeb2a26d429ccfc81fbc1
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Tue Nov 26 10:39:00 2024 +0800

    fbdev: efifb: Register sysfs groups through driver core
    
    [ Upstream commit 95cdd538e0e5677efbdf8aade04ec098ab98f457 ]
    
    The driver core can register and cleanup sysfs groups already.
    Make use of that functionality to simplify the error handling and
    cleanup.
    
    Also avoid a UAF race during unregistering where the sysctl attributes
    were usable after the info struct was freed.
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19b40ca62607cef78369549d1af091f2fd558931
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Nov 26 14:25:37 2024 +0800

    Bluetooth: MGMT: Fix possible crash on mgmt_index_removed
    
    [ Upstream commit f53e1c9c726d83092167f2226f32bd3b73f26c21 ]
    
    If mgmt_index_removed is called while there are commands queued on
    cmd_sync it could lead to crashes like the bellow trace:
    
    0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc
    0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]
    0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]
    0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]
    
    So while handling mgmt_index_removed this attempts to dequeue
    commands passed as user_data to cmd_sync.
    
    Fixes: 7cf5c2978f23 ("Bluetooth: hci_sync: Refactor remove Adv Monitor")
    Reported-by: jiaymao <quic_jiaymao@quicinc.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    [Xiangyu: BP to fix CVE: CVE-2024-49951, Minor conflict resolution]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f00f36db76eb8fd10d13e80e2590f23b5beaa54d
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Nov 26 14:25:36 2024 +0800

    Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue
    
    [ Upstream commit 505ea2b295929e7be2b4e1bc86ee31cb7862fb01 ]
    
    This adds functions to queue, dequeue and lookup into the cmd_sync
    list.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26d262b79a3587aaa84368586a55e9026c67841b
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Nov 26 19:23:25 2024 +0800

    drm/amd/display: Check null-initialized variables
    
    [ Upstream commit 367cd9ceba1933b63bc1d87d967baf6d9fd241d2 ]
    
    [WHAT & HOW]
    drr_timing and subvp_pipe are initialized to null and they are not
    always assigned new values. It is necessary to check for null before
    dereferencing.
    
    This fixes 2 FORWARD_NULL issues reported by Coverity.
    
    Reviewed-by: Nevenko Stupar <nevenko.stupar@amd.com>
    Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Signed-off-by: Jerry Zuo <jerry.zuo@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [Xiangyu: BP to fix CVE: CVE-2024-49898, Minor conflict resolution]
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e087c9738ee1cdeebde346f4dfc819e5f7057e90
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Tue Nov 26 18:10:51 2024 +0800

    drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func
    
    [ Upstream commit 28574b08c70e56d34d6f6379326a860b96749051 ]
    
    This commit adds a null check for the set_output_gamma function pointer
    in the dcn32_set_output_transfer_func function. Previously,
    set_output_gamma was being checked for null, but then it was being
    dereferenced without any null check. This could lead to a null pointer
    dereference if set_output_gamma is null.
    
    To fix this, we now ensure that set_output_gamma is not null before
    dereferencing it. We do this by adding a null check for set_output_gamma
    before the call to set_output_gamma.
    
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Alex Hung <alex.hung@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 304f8032d601d4f9322ca841cd0b573bd1beb158
Author: Marco Pagani <marpagan@redhat.com>
Date:   Mon Nov 25 13:38:16 2024 +0800

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

commit 18dc8366abb6cadcb77668b1a16434654e355d49
Author: Marco Pagani <marpagan@redhat.com>
Date:   Mon Nov 25 13:38:15 2024 +0800

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

commit ec79e6170bcae8a6036a4b6960f5e7e59a785601
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Nov 22 14:44:10 2024 +0100

    cifs: Fix buffer overflow when parsing NFS reparse points
    
    commit e2a8910af01653c1c268984855629d71fb81f404 upstream.
    
    ReparseDataLength is sum of the InodeType size and DataBuffer size.
    So to get DataBuffer size it is needed to subtract InodeType's size from
    ReparseDataLength.
    
    Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer
    at position after the end of the buffer because it does not subtract
    InodeType size from the length. Fix this problem and correctly subtract
    variable len.
    
    Member InodeType is present only when reparse buffer is large enough. Check
    for ReparseDataLength before accessing InodeType to prevent another invalid
    memory access.
    
    Major and minor rdev values are present also only when reparse buffer is
    large enough. Check for reparse buffer size before calling reparse_mkdev().
    
    Fixes: d5ecebc4900d ("smb3: Allow query of symlinks stored as reparse points")
    Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [use variable name symlink_buf, the other buf->InodeType accesses are
    not used in current version so skip]
    Signed-off-by: Mahmoud Adam <mngyadam@amazon.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc6a3f35bc9b3a8da1b195420a2e8d9fdadfa831
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Fri Nov 22 15:16:56 2024 +0800

    serial: sc16is7xx: fix invalid FIFO access with special register set
    
    [ Upstream commit 7d3b793faaab1305994ce568b59d61927235f57b ]
    
    When enabling access to the special register set, Receiver time-out and
    RHR interrupts can happen. In this case, the IRQ handler will try to read
    from the FIFO thru the RHR register at address 0x00, but address 0x00 is
    mapped to DLL register, resulting in erroneous FIFO reading.
    
    Call graph example:
        sc16is7xx_startup(): entry
        sc16is7xx_ms_proc(): entry
        sc16is7xx_set_termios(): entry
        sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set
        sc16is7xx_port_irq() entry            --> IIR is 0x0C
        sc16is7xx_handle_rx() entry
        sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is
                                   mapped to DLL (LCR=LCR_CONF_MODE_A)
        sc16is7xx_set_baud(): exit --> Restore access to general register set
    
    Fix the problem by claiming the efr_lock mutex when accessing the Special
    register set.
    
    Fixes: dfeae619d781 ("serial: sc16is7xx")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240723125302.1305372-3-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ Resolve minor conflicts ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9365368b483328639c03fc730448dccd5a25b6b
Author: Wang Liang <wangliang74@huawei.com>
Date:   Fri Nov 22 11:18:09 2024 +0800

    net: fix crash when config small gso_max_size/gso_ipv4_max_size
    
    [ Upstream commit 9ab5cf19fb0e4680f95e506d6c544259bf1111c4 ]
    
    Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow
    in sk_dst_gso_max_size(), which may trigger a BUG_ON crash,
    because sk->sk_gso_max_size would be much bigger than device limits.
    Call Trace:
    tcp_write_xmit
        tso_segs = tcp_init_tso_segs(skb, mss_now);
            tcp_set_skb_tso_segs
                tcp_skb_pcount_set
                    // skb->len = 524288, mss_now = 8
                    // u16 tso_segs = 524288/8 = 65535 -> 0
                    tso_segs = DIV_ROUND_UP(skb->len, mss_now)
        BUG_ON(!tso_segs)
    Add check for the minimum value of gso_max_size and gso_ipv4_max_size.
    
    Fixes: 46e6b992c250 ("rtnetlink: allow GSO maximums to be set on device creation")
    Fixes: 9eefedd58ae1 ("net: add gso_ipv4_max_size and gro_ipv4_max_size per device")
    Signed-off-by: Wang Liang <wangliang74@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20241023035213.517386-1-wangliang74@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Resolve minor conflicts to fix CVE-2024-50258 ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c894a74756478bb7aec894bcc513add3d554c0cf
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Thu Nov 21 14:46:07 2024 +0800

    closures: Change BUG_ON() to WARN_ON()
    
    [ Upstream commit 339b84ab6b1d66900c27bd999271cb2ae40ce812 ]
    
    If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON()
    
    For reference, this has popped up once in the CI, and we'll need more
    info to debug it:
    
    03240 ------------[ cut here ]------------
    03240 kernel BUG at lib/closure.c:21!
    03240 kernel BUG at lib/closure.c:21!
    03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
    03240 Modules linked in:
    03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570
    03240 Hardware name: linux,dummy-virt (DT)
    03240 Workqueue: btree_update btree_interior_update_work
    03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
    03240 pc : closure_put+0x224/0x2a0
    03240 lr : closure_put+0x24/0x2a0
    03240 sp : ffff0000d12071c0
    03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360
    03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040
    03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168
    03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001
    03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974
    03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d
    03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e
    03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b
    03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954
    03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000
    03240 Call trace:
    03240  closure_put+0x224/0x2a0
    03240  bch2_check_for_deadlock+0x910/0x1028
    03240  bch2_six_check_for_deadlock+0x1c/0x30
    03240  six_lock_slowpath.isra.0+0x29c/0xed0
    03240  six_lock_ip_waiter+0xa8/0xf8
    03240  __bch2_btree_node_lock_write+0x14c/0x298
    03240  bch2_trans_lock_write+0x6d4/0xb10
    03240  __bch2_trans_commit+0x135c/0x5520
    03240  btree_interior_update_work+0x1248/0x1c10
    03240  process_scheduled_works+0x53c/0xd90
    03240  worker_thread+0x370/0x8c8
    03240  kthread+0x258/0x2e8
    03240  ret_from_fork+0x10/0x20
    03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000)
    03240 ---[ end trace 0000000000000000 ]---
    03240 Kernel panic - not syncing: Oops - BUG: Fatal exception
    03240 SMP: stopping secondary CPUs
    03241 SMP: failed to stop secondary CPUs 13,15
    03241 Kernel Offset: disabled
    03241 CPU features: 0x00,00000003,80000008,4240500b
    03241 Memory Limit: none
    03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---
    03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    [ Resolve minor conflicts to fix CVE-2024-42252 ]
    Signed-off-by: Bin Lan <bin.lan.cn@windriver.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 889ec2e427456dbf7f5ac6d166934041e695d6a2
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Nov 8 06:08:36 2024 -0800

    ipmr: Fix access to mfc_cache_list without lock held
    
    [ Upstream commit e28acc9c1ccfcb24c08e020828f69d0a915b06ae ]
    
    Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the
    following code flow, the RCU read lock is not held, causing the
    following error when `RCU_PROVE` is not held. The same problem might
    show up in the IPv6 code path.
    
            6.12.0-rc5-kbuilder-01145-gbac17284bdcb #33 Tainted: G            E    N
            -----------------------------
            net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!!
    
            rcu_scheduler_active = 2, debug_locks = 1
                       2 locks held by RetransmitAggre/3519:
                        #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290
                        #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90
    
            stack backtrace:
                        lockdep_rcu_suspicious
                        mr_table_dump
                        ipmr_rtm_dumproute
                        rtnl_dump_all
                        rtnl_dumpit
                        netlink_dump
                        __netlink_dump_start
                        rtnetlink_rcv_msg
                        netlink_rcv_skb
                        netlink_unicast
                        netlink_sendmsg
    
    This is not a problem per see, since the RTNL lock is held here, so, it
    is safe to iterate in the list without the RCU read lock, as suggested
    by Eric.
    
    To alleviate the concern, modify the code to use
    list_for_each_entry_rcu() with the RTNL-held argument.
    
    The annotation will raise an error only if RTNL or RCU read lock are
    missing during iteration, signaling a legitimate problem, otherwise it
    will avoid this false positive.
    
    This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls
    this function as well.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20241108-ipmr_rcu-v2-1-c718998e209b@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f57b5752f5dab8e23034f8e6d11bd93f3ab467de
Author: Harith G <harith.g@alifsemi.com>
Date:   Wed Sep 18 06:57:53 2024 +0100

    ARM: 9420/1: smp: Fix SMP for xip kernels
    
    [ Upstream commit 9e9b0cf9319b4db143014477b0bc4b39894248f1 ]
    
    Fix the physical address calculation of the following to get smp working
    on xip kernels.
    - secondary_data needed for secondary cpu bootup.
    - secondary_startup address passed through psci.
    - identity mapped code region needed for enabling mmu for secondary cpus.
    
    Signed-off-by: Harith George <harith.g@alifsemi.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61e43f619e17d6633a0a191be7eaae8ed11f6cfb
Author: Eryk Zagorski <erykzagorski@gmail.com>
Date:   Mon Nov 11 11:45:21 2024 -0500

    ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry
    
    [ Upstream commit 6f891ca15b017707840c9e7f5afd9fc6cfd7d8b1 ]
    
    This patch switches the P-125 quirk entry to use a composite quirk as the
    P-125 supplies both MIDI and Audio like many of the other Yamaha
    keyboards
    
    Signed-off-by: Eryk Zagorski <erykzagorski@gmail.com>
    Link: https://patch.msgid.link/20241111164520.9079-2-erykzagorski@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbd1ed34c886d8c3c718ea691c384df54da76509
Author: Yuli Wang <wangyuli@uniontech.com>
Date:   Tue Nov 12 16:35:39 2024 +0800

    LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS
    
    [ Upstream commit c859900a841b0a6cd9a73d16426465e44cdde29c ]
    
    This is a trivial cleanup, commit c62da0c35d58518d ("mm/vma: define a
    default value for VM_DATA_DEFAULT_FLAGS") has unified default values of
    VM_DATA_DEFAULT_FLAGS across different platforms.
    
    Apply the same consistency to LoongArch.
    
    Suggested-by: Wentao Guan <guanwentao@uniontech.com>
    Signed-off-by: Yuli Wang <wangyuli@uniontech.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6125482489ada95c0f1053e09cc7ecfb116721fb
Author: John Watts <contact@jookia.org>
Date:   Fri Nov 8 12:37:15 2024 +1100

    ASoC: audio-graph-card2: Purge absent supplies for device tree nodes
    
    [ Upstream commit f8da001ae7af0abd9f6250c02c01a1121074ca60 ]
    
    The audio graph card doesn't mark its subnodes such as multi {}, dpcm {}
    and c2c {} as not requiring any suppliers. This causes a hang as Linux
    waits for these phantom suppliers to show up on boot.
    Make it clear these nodes have no suppliers.
    
    Example error message:
    [   15.208558] platform 2034000.i2s: deferred probe pending: platform: wait for supplier /sound/multi
    [   15.208584] platform sound: deferred probe pending: asoc-audio-graph-card2: parse error
    
    Signed-off-by: John Watts <contact@jookia.org>
    Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://patch.msgid.link/20241108-graph_dt_fix-v1-1-173e2f9603d6@jookia.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 747ad49dd851354e5bcfbe9226e372ec9843dc9d
Author: David Wang <00107082@163.com>
Date:   Wed Nov 6 10:12:28 2024 +0800

    proc/softirqs: replace seq_printf with seq_put_decimal_ull_width
    
    [ Upstream commit 84b9749a3a704dcc824a88aa8267247c801d51e4 ]
    
    seq_printf is costy, on a system with n CPUs, reading /proc/softirqs
    would yield 10*n decimal values, and the extra cost parsing format string
    grows linearly with number of cpus. Replace seq_printf with
    seq_put_decimal_ull_width have significant performance improvement.
    On an 8CPUs system, reading /proc/softirqs show ~40% performance
    gain with this patch.
    
    Signed-off-by: David Wang <00107082@163.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cddb33958727bb6605b8b035fec9c9a963e44e0a
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Aug 25 15:21:31 2024 +0200

    drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less strict
    
    [ Upstream commit 052ef642bd6c108a24f375f9ad174b97b425a50b ]
    
    There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it
    turns out that the 2G version has a DMI product name of
    "CHERRYVIEW D1 PLATFORM" where as the 4G version has
    "CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are
    unique enough that the product-name check is not necessary.
    
    Drop the product-name check so that the existing DMI match for the 4G
    RAM version also matches the 2G RAM version.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240825132131.6643-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dccfd9a4df809977195ab5498a46b6ac3bac733d
Author: Luo Yifan <luoyifan@cmss.chinamobile.com>
Date:   Thu Nov 7 09:59:36 2024 +0800

    ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()
    
    [ Upstream commit 23569c8b314925bdb70dd1a7b63cfe6100868315 ]
    
    This patch checks if div is less than or equal to zero (div <= 0). If
    div is zero or negative, the function returns -EINVAL, ensuring the
    division operation is safe to perform.
    
    Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com>
    Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com>
    Link: https://patch.msgid.link/20241107015936.211902-1-luoyifan@cmss.chinamobile.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d1838582d7925a86a4d5e7fe2e12e7dc6d8eccc
Author: Luo Yifan <luoyifan@cmss.chinamobile.com>
Date:   Wed Nov 6 09:46:54 2024 +0800

    ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()
    
    [ Upstream commit 63c1c87993e0e5bb11bced3d8224446a2bc62338 ]
    
    This patch checks if div is less than or equal to zero (div <= 0). If
    div is zero or negative, the function returns -EINVAL, ensuring the
    division operation (*prate / div) is safe to perform.
    
    Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com>
    Link: https://patch.msgid.link/20241106014654.206860-1-luoyifan@cmss.chinamobile.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a7911bdcc65601d2ad5a0ef4df5a443baed89bf
Author: Markus Petri <mp@mpetri.org>
Date:   Thu Nov 7 10:40:20 2024 +0100

    ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6
    
    [ Upstream commit 8c21e40e1e481f7fef6e570089e317068b972c45 ]
    
    Another model of Thinkpad E14 Gen 6 (21M4)
    needs a quirk entry for the dmic to be detected.
    
    Signed-off-by: Markus Petri <mp@mpetri.org>
    Link: https://patch.msgid.link/20241107094020.1050935-1-mp@localhost
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78d10f2b0d0ab406df1792a49d598fb8aff6bbc1
Author: Vishnu Sankar <vishnuocv@gmail.com>
Date:   Wed Nov 6 08:55:05 2024 +0900

    platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect fan speed
    
    [ Upstream commit 1be765b292577c752e0b87bf8c0e92aff6699d8e ]
    
    Fix for Thinkpad's with ECFW showing incorrect fan speed. Some models use
    decimal instead of hexadecimal for the speed stored in the EC registers.
    For example the rpm register will have 0x4200 instead of 0x1068, here
    the actual RPM is "4200" in decimal.
    
    Add a quirk to handle this.
    
    Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
    Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Link: https://lore.kernel.org/r/20241105235505.8493-1-vishnuocv@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9529e0e5994b58f02a5f44cd344734cf53da72b8
Author: Alexander Hölzl <alexander.hoelzl@gmx.net>
Date:   Wed Oct 23 16:52:57 2024 +0200

    can: j1939: fix error in J1939 documentation.
    
    [ Upstream commit b6ec62e01aa4229bc9d3861d1073806767ea7838 ]
    
    The description of PDU1 format usage mistakenly referred to PDU2 format.
    
    Signed-off-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://patch.msgid.link/20241023145257.82709-1-alexander.hoelzl@gmx.net
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af010abad5e2acae2e300a8cf9016c60761a82bc
Author: zhang jiao <zhangjiao2@cmss.chinamobile.com>
Date:   Thu Sep 12 12:50:31 2024 +0800

    tools/lib/thermal: Remove the thermal.h soft link when doing make clean
    
    [ Upstream commit c5426dcc5a3a064bbd2de383e29035a14fe933e0 ]
    
    Run "make -C tools thermal" can create a soft link for thermal.h in
    tools/include/uapi/linux.  Just rm it when make clean.
    
    Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com>
    Link: https://lore.kernel.org/r/20240912045031.18426-1-zhangjiao2@cmss.chinamobile.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d7d478d39a7724b4c9423e35be5b4307244ff55
Author: Kurt Borja <kuurtb@gmail.com>
Date:   Thu Oct 31 12:44:42 2024 -0300

    platform/x86: dell-wmi-base: Handle META key Lock/Unlock events
    
    [ Upstream commit ec61f0bb4feec3345626a2b93b970b6719743997 ]
    
    Some Alienware devices have a key that locks/unlocks the Meta key. This
    key triggers a WMI event that should be ignored by the kernel, as it's
    handled by internally the firmware.
    
    There is no known way of changing this default behavior. The firmware
    would lock/unlock the Meta key, regardless of how the event is handled.
    
    Tested on an Alienware x15 R1.
    
    Signed-off-by: Kurt Borja <kuurtb@gmail.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20241031154441.6663-2-kuurtb@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad5112e48ca11bd820e5839245970a2860a8472b
Author: Kurt Borja <kuurtb@gmail.com>
Date:   Thu Oct 31 12:40:24 2024 -0300

    platform/x86: dell-smbios-base: Extends support to Alienware products
    
    [ Upstream commit a36b8b84ac4327b90ef5a22bc97cc96a92073330 ]
    
    Fixes the following error:
    
    dell_smbios: Unable to run on non-Dell system
    
    Which is triggered after dell-wmi driver fails to initialize on
    Alienware systems, as it depends on dell-smbios.
    
    This effectively extends dell-wmi, dell-smbios and dcdbas support to
    Alienware devices, that might share some features of the SMBIOS intereface
    calling interface with other Dell products.
    
    Tested on an Alienware X15 R1.
    
    Signed-off-by: Kurt Borja <kuurtb@gmail.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20241031154023.6149-2-kuurtb@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e920aa8d2c69f17481da13b60c376d0553bd2a5b
Author: Mikhail Rudenko <mike.rudenko@gmail.com>
Date:   Thu Oct 17 21:37:28 2024 +0300

    regulator: rk808: Add apply_bit for BUCK3 on RK809
    
    [ Upstream commit 5e53e4a66bc7430dd2d11c18a86410e3a38d2940 ]
    
    Currently, RK809's BUCK3 regulator is modelled in the driver as a
    configurable regulator with 0.5-2.4V voltage range. But the voltage
    setting is not actually applied, because when bit 6 of
    PMIC_POWER_CONFIG register is set to 0 (default), BUCK3 output voltage
    is determined by the external feedback resistor. Fix this, by setting
    bit 6 when voltage selection is set. Existing users which do not
    specify voltage constraints in their device trees will not be affected
    by this change, since no voltage setting is applied in those cases,
    and bit 6 is not enabled.
    
    Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
    Link: https://patch.msgid.link/20241017-rk809-dcdc3-v1-1-e3c3de92f39c@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f785b89a935311a09642026d64e296ec7d92e54
Author: Charles Han <hanchunchao@inspur.com>
Date:   Sun Sep 29 15:23:49 2024 +0800

    soc: qcom: Add check devm_kasprintf() returned value
    
    [ Upstream commit e694d2b5c58ba2d1e995d068707c8d966e7f5f2a ]
    
    devm_kasprintf() can return a NULL pointer on failure but this
    returned value in qcom_socinfo_probe() is not checked.
    
    Signed-off-by: Charles Han <hanchunchao@inspur.com>
    Link: https://lore.kernel.org/r/20240929072349.202520-1-hanchunchao@inspur.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc9a5182d34934b13ff60502657238f563381d3b
Author: Benoît Monin <benoit.monin@gmx.fr>
Date:   Thu Oct 24 17:11:13 2024 +0200

    net: usb: qmi_wwan: add Quectel RG650V
    
    [ Upstream commit 6b3f18a76be6bbd237c7594cf0bf2912b68084fe ]
    
    Add support for Quectel RG650V which is based on Qualcomm SDX65 chip.
    The composition is DIAG / NMEA / AT / AT / QMI.
    
    T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
    D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P: Vendor=2c7c ProdID=0122 Rev=05.15
    S: Manufacturer=Quectel
    S: Product=RG650V-EU
    S: SerialNumber=xxxxxxx
    C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=9ms
    I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=9ms
    I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=9ms
    
    Signed-off-by: Benoît Monin <benoit.monin@gmx.fr>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20241024151113.53203-1-benoit.monin@gmx.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79b09458eb18bcf7bb6bb2d05a365a3df2488d28
Author: Jiayuan Chen <mrpre@163.com>
Date:   Mon Oct 28 14:52:26 2024 +0800

    bpf: fix filed access without lock
    
    [ Upstream commit a32aee8f0d987a7cba7fcc28002553361a392048 ]
    
    The tcp_bpf_recvmsg_parser() function, running in user context,
    retrieves seq_copied from tcp_sk without holding the socket lock, and
    stores it in a local variable seq. However, the softirq context can
    modify tcp_sk->seq_copied concurrently, for example, n tcp_read_sock().
    
    As a result, the seq value is stale when it is assigned back to
    tcp_sk->copied_seq at the end of tcp_bpf_recvmsg_parser(), leading to
    incorrect behavior.
    
    Due to concurrency, the copied_seq field in tcp_bpf_recvmsg_parser()
    might be set to an incorrect value (less than the actual copied_seq) at
    the end of function: 'WRITE_ONCE(tcp->copied_seq, seq)'. This causes the
    'offset' to be negative in tcp_read_sock()->tcp_recv_skb() when
    processing new incoming packets (sk->copied_seq - skb->seq becomes less
    than 0), and all subsequent packets will be dropped.
    
    Signed-off-by: Jiayuan Chen <mrpre@163.com>
    Link: https://lore.kernel.org/r/20241028065226.35568-1-mrpre@163.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 665edd4bc06ec01840616f3e84b93cba1d1a7d36
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Oct 29 09:23:20 2024 +0000

    x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB
    
    [ Upstream commit fce9642c765a18abd1db0339a7d832c29b68456a ]
    
    node_to_amd_nb() is defined to NULL in non-AMD configs:
    
      drivers/platform/x86/amd/hsmp/plat.c: In function 'init_platform_device':
      drivers/platform/x86/amd/hsmp/plat.c:165:68: error: dereferencing 'void *' pointer [-Werror]
        165 |                 sock->root                      = node_to_amd_nb(i)->root;
            |                                                                    ^~
      drivers/platform/x86/amd/hsmp/plat.c:165:68: error: request for member 'root' in something not a structure or union
    
    Users of the interface who also allow COMPILE_TEST will cause the above build
    error so provide an inline stub to fix that.
    
      [ bp: Massage commit message. ]
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20241029092329.3857004-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c4188b883d36733f0e1a19a6161cb1d292123e1
Author: Piyush Raj Chouhan <piyushchouhan1598@gmail.com>
Date:   Mon Oct 28 15:55:16 2024 +0000

    ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13
    
    [ Upstream commit ef5fbdf732a158ec27eeba69d8be851351f29f73 ]
    
    Infinix ZERO BOOK 13 has a 2+2 speaker system which isn't probed correctly.
    This patch adds a quirk with the proper pin connections.
    Also The mic in this laptop suffers too high gain resulting in mostly
    fan noise being recorded,
    This patch Also limit mic boost.
    
    HW Probe for device; https://linux-hardware.org/?probe=a2e892c47b
    
    Test: All 4 speaker works, Mic has low noise.
    
    Signed-off-by: Piyush Raj Chouhan <piyushchouhan1598@gmail.com>
    Link: https://patch.msgid.link/20241028155516.15552-1-piyuschouhan1598@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1d17ef00f5b6a462a57576948a151888865582d
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Tue Oct 29 11:13:24 2024 +0800

    selftests/watchdog-test: Fix system accidentally reset after watchdog-test
    
    [ Upstream commit dc1308bee1ed03b4d698d77c8bd670d399dcd04d ]
    
    When running watchdog-test with 'make run_tests', the watchdog-test will
    be terminated by a timeout signal(SIGTERM) due to the test timemout.
    
    And then, a system reboot would happen due to watchdog not stop. see
    the dmesg as below:
    ```
    [ 1367.185172] watchdog: watchdog0: watchdog did not stop!
    ```
    
    Fix it by registering more signals(including SIGTERM) in watchdog-test,
    where its signal handler will stop the watchdog.
    
    After that
     # timeout 1 ./watchdog-test
     Watchdog Ticking Away!
     .
     Stopping watchdog ticks...
    
    Link: https://lore.kernel.org/all/20241029031324.482800-1-lizhijian@fujitsu.com/
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f263bd11707e511220234383871b60bd49573fdd
Author: Benjamin Große <ste3ls@gmail.com>
Date:   Sun Oct 20 18:41:28 2024 +0100

    usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver
    
    [ Upstream commit 94c11e852955b2eef5c4f0b36cfeae7dcf11a759 ]
    
    This patch adds support for another Lenovo Mini dock 0x17EF:0x3098 to the
    r8152 driver. The device has been tested on NixOS, hotplugging and sleep
    included.
    
    Signed-off-by: Benjamin Große <ste3ls@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20241020174128.160898-1-ste3ls@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57fd15bdc0499c4af18940f9d0dadce159078383
Author: Ben Greear <greearb@candelatech.com>
Date:   Thu Oct 10 13:39:54 2024 -0700

    mac80211: fix user-power when emulating chanctx
    
    [ Upstream commit 9b15c6cf8d2e82c8427cd06f535d8de93b5b995c ]
    
    ieee80211_calc_hw_conf_chan was ignoring the configured
    user_txpower.  If it is set, use it to potentially decrease
    txpower as requested.
    
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Link: https://patch.msgid.link/20241010203954.1219686-1-greearb@candelatech.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 916eaa5814b1b1e70b46a56fb9cf36757b7cd64c
Author: Daniel Gabay <daniel.gabay@intel.com>
Date:   Thu Oct 10 14:05:03 2024 +0300

    wifi: iwlwifi: mvm: Use the sync timepoint API in suspend
    
    [ Upstream commit 9715246ca0bfc9feaec1b4ff5b3d38de65a7025d ]
    
    When starting the suspend flow, HOST_D3_START triggers an _async_
    firmware dump collection for debugging purposes. The async worker
    may race with suspend flow and fail to get NIC access, resulting in
    the following warning:
    "Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)"
    
    Fix this by switching to the sync version to ensure the dump
    completes before proceeding with the suspend flow, avoiding
    potential race issues.
    
    Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20241010140328.9aae318cd593.I4b322009f39489c0b1d8893495c887870f73ed9c@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4c5d4f4c91de5970e7bc9bc4961a7a0954b9f92
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Oct 25 11:02:21 2024 +0200

    ASoC: Intel: sst: Support LPE0F28 ACPI HID
    
    [ Upstream commit 6668610b4d8ce9a3ee3ed61a9471f62fb5f05bf9 ]
    
    Some old Bay Trail tablets which shipped with Android as factory OS
    have the SST/LPE audio engine described by an ACPI device with a
    HID (Hardware-ID) of LPE0F28 instead of 80860F28.
    
    Add support for this. Note this uses a new sst_res_info for just
    the LPE0F28 case because it has a different layout for the IO-mem ACPI
    resources then the 80860F28.
    
    An example of a tablet which needs this is the Vexia EDU ATLA 10 tablet,
    which has been distributed to schools in the Spanish Andalucía region.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patch.msgid.link/20241025090221.52198-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd3700860b7acc2e269a39b9acd6e0ebbbab093b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 24 23:16:15 2024 +0200

    ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet
    
    [ Upstream commit 0107f28f135231da22a9ad5756bb16bd5cada4d5 ]
    
    The Vexia Edu Atla 10 tablet mostly uses the BYTCR tablet defaults,
    but as happens on more models it is using IN1 instead of IN3 for
    its internal mic and JD_SRC_JD2_IN4N instead of JD_SRC_JD1_IN4P
    for jack-detection.
    
    Add a DMI quirk for this to fix the internal-mic and jack-detection.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patch.msgid.link/20241024211615.79518-2-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eade0698b88e872e897059494d18f04effe963d7
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 24 23:16:14 2024 +0200

    ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec
    
    [ Upstream commit d48696b915527b5bcdd207a299aec03fb037eb17 ]
    
    On some x86 Bay Trail tablets which shipped with Android as factory OS,
    the DSDT is so broken that the codec needs to be manually instantatiated
    by the special x86-android-tablets.ko "fixup" driver for cases like this.
    
    This means that the codec-dev cannot be retrieved through its ACPI fwnode,
    add support to the bytcr_rt5640 machine driver for such manually
    instantiated rt5640 i2c_clients.
    
    An example of a tablet which needs this is the Vexia EDU ATLA 10 tablet,
    which has been distributed to schools in the Spanish Andalucía region.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patch.msgid.link/20241024211615.79518-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>