summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
19 hoursMerge v7.2.5linux-rolling-stableGreg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursLinux 7.2.5v7.2.5linux-7.2.yGreg Kroah-Hartman
Link: https://lore.kernel.org/r/20260909134230.441546314@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Benjamin Boortz <bennib@mailbox.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursksmbd: zero pipe read compound paddingNamjae Jeon
commit 73f860489e3be2245598d1819226304fc5b87291 upstream. Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer. Fixes: e2b76ab8b5c9 ("ksmbd: add support for read compound") Reported-by: Cheryl Babcock <cheryl@renat.io> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursPCI: Allow per function PCI slots to fix slot reset on s390Farhan Ali
[ Upstream commit dcc5bec09e23bbc4f9de055a11fce9937244f2c8 ] On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES. Fixes: 44510d6fa0c0 ("s390/pci: Handling multifunctions") Suggested-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-3-alifm@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursPCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder valueFarhan Ali
[ Upstream commit c243e6c470c4695965cc8287767925bc1d9a7867 ] Introduce a constant for placeholder value and update the kerneldoc for pci_create_slot() to reference PCI_SLOT_PLACEHOLDER instead of -1 throughout. No functional change. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Tyrel Datwyler <tyreld@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Link: https://patch.msgid.link/20260805165518.794-2-alifm@linux.ibm.com Stable-dep-of: dcc5bec09e23 ("PCI: Allow per function PCI slots to fix slot reset on s390") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursmm/damon/vaddr: drop last same folio access check optimizationSJ Park
commit 831846078caa14b7d00b2ccca8b8fe522afe3204 upstream. The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SJ Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursmm/damon/paddr: drop last same folio access check reuse optimizationSJ Park
commit f23f0aa62b2f32c2b12f95959fc4603ef81678b2 upstream. It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: SJ Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 5.16.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursmm/damon/ops-common: use nr_accesses moving sum for quota scoreSJ Park
commit 6c25083f7ae7e2660d766169e5b4d3e96010503f upstream. Since commit 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval"), DAMOS scheme can be applied at any time. At that time, nr_accesses may not be fully aggregated. But the quota prioritization score is calculated using the not fully aggregated count. As a result, the performance of DAMOS could be degraded. Fix by using damon_nr_accesses_mvsum() instead. The user impact of the issue is suboptimum DAMOS performance under certain setups. Nonetheless, the bug was there from the beginning of the setup availability. In other words, the suboptimum performance is the baseline of the setup and hence it didn't cause regression. Also the extent of the suboptimality was not big enough to be found from users and testers. Still, this is a clear bug that is better to be fixed, and can be easily fixed. Link: https://lore.kernel.org/20260719161136.90191-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SJ Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 6.7.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursmm/damon/core: avoid infinite kdamond_merge_regions() internal loopSJ Park
commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd upstream. Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 6.10.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hourspower: supply: ab8500_fg: fix use-after-free on removeFan Wu
[ Upstream commit 75b1e88d34254f4fb7753345e21bfee47abddd7f ] ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool. Fixes: 13151631b5bd ("ab8500-fg: A8500 fuel gauge driver") Cc: stable@vger.kernel.org # v6.10+ Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260802020316.417757-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hourspower: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe()Pan Chuang
[ Upstream commit aa5f4decedfb4fc5cd0fe49ab256ad4304d192e4 ] The devm_request_threaded_irq() and devm_request_irq() now automatically log detailed error messages on failure. This eliminates the need for driver-specific dev_err() and dev_err_probe() calls that previously printed generic messages. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260709033428.362970-7-panchuang@vivo.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Stable-dep-of: 75b1e88d3425 ("power: supply: ab8500_fg: fix use-after-free on remove") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursremoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id checkMukesh Ojha
[ Upstream commit c06c5ab4945392d2c2aded6d832ab6b58cabe351 ] All other call sites of qcom_scm_pas_metadata_release() for the DTB context are guarded by a check on pas->dtb_pas_id, but the call inside qcom_pas_load() was not. Fix this by moving the call to the guarded block. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> [ changed qcom_pas_metadata_release() to qcom_scm_pas_metadata_release() for the older branch API. ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursrpcrdma: arm rn_done before publishing the notificationChuck Lever
[ Upstream commit 5b06f706374c37375bdff9d21cc10e61df925a92 ] rpcrdma_rn_register() inserts @rn into rd_xa with xa_alloc() before storing the caller's callback in rn->rn_done. The xarray makes @rn reachable to rpcrdma_remove_one(), which walks rd_xa and invokes rn->rn_done(rn) for every registered notification. A device removal that races a fresh registration can therefore observe @rn with rn_done still NULL, because the notification objects are zero allocated by their owners, and call through a NULL function pointer. Store rn->rn_done before xa_alloc() publishes @rn. The xarray's store-side and load-side ordering then guarantees that any CPU which finds @rn in rd_xa also observes the armed callback. rpcrdma_rn_unregister() treats a non-NULL rn_done as the sentinel for a completed registration, so the early store must not survive a failed registration. Clear rn_done again when xa_alloc() fails. Were it left set, the failed-accept cleanup path would call rpcrdma_rn_unregister() on an @rn that was never inserted, erasing an unrelated rd_xa slot and underflowing rd_kref. Fixes: 7e86845a0346 ("rpcrdma: Implement generic device removal") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260601201703.46078-1-cel@kernel.org Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursbpf: Disable preemption in bpf_get_stackidJiri Olsa
[ Upstream commit 15f1bd8574662f1b7b26aaa2e23ebf4066f0117d ] The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled. Fixes: d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE") Reported-by: Tao Chen <chen.dylane@linux.dev> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260803210149.296496-6-jolsa@kernel.org Closes: https://lore.kernel.org/bpf/20260206090653.1336687-2-chen.dylane@linux.dev/ Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursbpf: Use stack id functions instead of __bpf_get_stackidJiri Olsa
[ Upstream commit 09b3fd6caa0b57f8a39254ee5db3af30bdd53c18 ] Replacing __bpf_get_stackid calls with sequence of following functions: stackid_fastpath stackid_new_bucket stackid_install This makes code more structured and allows us to easily disable preemption only in bpf_get_stackid in following changes. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260803210149.296496-5-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursbpf: Factor stackid_new_bucket from __bpf_get_stackidJiri Olsa
[ Upstream commit bb4e6f4e1b68fe60c04ca04c564c6624e837dbf4 ] The new stackid_new_bucket allocates the new bucket and initializes it with the trace data. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260803210149.296496-4-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursbpf: Factor stackid_fastpath function from __bpf_get_stackidJiri Olsa
[ Upstream commit 0ca56befcffec3a6c9d1842eae06c74e1cf41f11 ] The new stackid_fastpath does the fast stack hash and trace check, that does not need new bucket allocation. It covers both just-ip and buildid code paths. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260803210149.296496-3-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursbpf: Factor stackid_init function from __bpf_get_stackidJiri Olsa
[ Upstream commit 15b837759a97237d647962f9943afe0d55af615a ] The new stackid_init function stores all the necessary bits for stackid trace and it will be used by other functions in following changes. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260803210149.296496-2-jolsa@kernel.org Stable-dep-of: 15f1bd857466 ("bpf: Disable preemption in bpf_get_stackid") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursksmbd: fix use-after-free in oplock break notificationAbdifatah Suruur
commit 0e753899627b5e28a9fea8bca98262a6f65a2452 upstream. smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures. Fixes: b003086d7696 ("ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers") Cc: stable@vger.kernel.org Signed-off-by: Abdifatah Suruur <suruurism@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/gsp: fix vblank interrupts on GB20xMohamed Ahmed
commit 5bb489b333237c1bf63a891a4362986253a0060a upstream. The GSP path programs per-head timing (vblank) interrupts the same way on every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend around four message-based kernel vectors (high latency, low latency, PMU, and GSP) and moved RM head-timing interrupts to the dedicated low-latency vector: - The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502.c from 575.51.02 on, and v05_01 dev_disp.h). - The vector is reported as a separate interrupt table entry, MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVectors). - The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) at 0x611f34 after servicing (kdispServiceInterrupt -> kdispIntrRetrigger_v05_01). The event latch (0x611800), per-head status (0x611c00), and dispatch summary (0x611ec0) the interrupt handler uses are unchanged on GB20x (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 remain for DISPv0502+). On GB20x the old code enables head timing onto the legacy vector, leaves its handler there, and never re-arms the message-based vectors. Page flips still complete (nv50 sends those events from the commit path), so the desktop looks fine while DRM vblank waits and vblank sequence queries are affected. Supply GB20x vblank enables and an interrupt handler that re-arms the vector after servicing through gb202_gsp_disp, translate the low-latency interrupt table entry as a second NVKM_ENGINE_DISP instance, and add a gsp.intr_low_latency flag so r535_disp_oneinit() attaches the handler to that instance. GB20x was the last cross-file user of the TU1xx vblank enables, so make those static and drop their head.h prototypes. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-9-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: fix head state readback on GB20xMohamed Ahmed
commit 9421dfe912e55360e6b9301a110acb00df7e7320 upstream. The GSP path reads armed head state and the RG scanout position through gv100_head_state() and gv100_head_rgpos() on every generation. gv100_head_state() reads the core channel's state mirror at a 0x400 per-head stride, which NVD5.0 (GB20x) doubled. Per NVIDIA's published CA7D class header every HEAD_SET method sits at 0x2000 + head * 0x800, while the mirror bases are unchanged (assembly at 0x680000, armed at +0x8000, per OpenRM's v03_00 channel-user-base HAL which is still used on DISPv0502). Add gb202_head_state(), the same readback at the 0x800 stride, and a gb202_gsp_head table to supply it. gv100_head_rgpos() is kept. The RG registers keep their per-head 0x800 stride on NVD5.0, and OpenRM's kdispReadRgLineCountAndFrameCount_v03_00 still reads NV_PDISP_RG_DPCA on DISPv0502. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-8-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20xMohamed Ahmed
commit 764deff8450c9a83e335c17c32ea258ec25bb71e upstream. The GSP path brackets audio enablement with a General Control Packet AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook, which every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were compacted and the old generic and VSI units are gone (ACR keeps slot 2) and the GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack 0x6f004c from NVIDIA's published clc971.h. The same offsets are also used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips). The old addresses are reserved on GB20x, so the AVMute writes were silent no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio() already sends through the SET_OD_PACKET RM control. Add a GB20x GCP writer using the new offsets and hook it into gb202_gsp_disp, keeping the direct MMIO path in sync with the hardware as on earlier chips. Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register also carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP fields are generated (hardware or from the driver, with the default being HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-6-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: fix HDMI vendor infoframes on GB20xMohamed Ahmed
commit 92f09dcb4e8473ab25764e950994ab7b6abce6dd upstream. The GSP path reuses the GV100 direct-MMIO infoframe writers on every chip. On GB20x that is only half right as while the legacy SF AVI unit is unchanged, the legacy VSI unit at 0x6f0100 was removed, so gv100_sor_hdmi_infoframe_vsi() writes into a reserved area and no vendor infoframe ever reaches the HW. This affects HDMI-VIC signalling which can impact some 4K modes for legacy HDMI 1.4 sinks. GB20x (NVDisplay 5.0+) reorganised the SF HDMI packet units. Per NVIDIA's published C971/CA71 DISP_SF_USER class headers, only three legacy units remain (AVI at +0x000, GCP at +0x040, ACR at +0x080), and vendor infoframes must instead be sent through the shared generic infoframe units at +0x130, whose 9-dword packet slots are loaded through the shared data port at +0x3f0/+0x3f4. Add a VSI writer using the same programming sequence OpenRM uses on these chips (nvhdmipkt_C971.c, programAdvancedInfoframeC971()): disable the unit and wait for it to idle, clear the SENT status, write the packet through the data port with a zero inserted in HB3 after the three header bytes, then enable the unit for every-frame transmission during vblank. Generic unit 1 is used for the VSI, matching the slot assignment in NVIDIA's nvkms (NVHDMIPKT_TYPE_SHARED_GENERIC2, unit 0 is reserved for extended metadata packets and unit 2 for the HDR DRM infoframe, if those are wired up later). GB20x so far shared GA10x's display entry point. Give it its own, gb202_disp_new(), with a gb202_gsp_disp table that supplies the VSI writer to the GSP path and otherwise carries the same hooks as GA10x. The following fixes fill in the rest of the GB20x differences there. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-5-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooksMohamed Ahmed
commit 9886aad51f4b5e7082209a153e404bcd8101356c upstream. The GSP-RM display code in rm/r535/disp.c borrows a few register-programming routines from engine/disp (the head-timing interrupt handler, vblank enables, armed head state and scanout position readback, the AVI/VSI infoframe writers and the GCP AVMute write) and so far picked them by name, which means it has to know which chip it runs on the moment a generation changes any of them. Give nvkm_disp_func a .gsp table that each chip fills with exactly those hooks, add tu102_gsp_disp (TU1xx) and ga102_gsp_disp (GA10x onwards) carrying the current functions, hand them to r535_disp_new() instead of the full hardware tables, and make rm/r535/disp.c call through the hooks. The head hooks are a whole nvkm_head_func, so r535_head goes away and the chip's own table is handed to nvkm_head_new_(). r535_sor_hdmi gets infoframe forwarders, r535_sor_hdmi_audio() calls the GCP hook, and the interrupt handler comes from the table. The tables are per chip even though the two currently coincide, so a generation that changes a hook only touches its own file. rm/r535/disp.c no longer contains chip-specific register code, and a new display generation only has to provide its own table. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-4-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/dispMohamed Ahmed
commit eb1ffc3dc72d379a41e367a44b99fb61a15bf8ba upstream. r535_sor_hdmi_audio() pairs two RM controls (a SET_OD_PACKET carrying the same General Control Packet, and the audio mute-stream toggle) with a direct write of the GCP AVMute bit through the SF GCP unit. The controls are RM and stay, but the direct write is register programming and moves next to the other per-chip display code as tu102_sor_hdmi_gcp(). No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-3-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.cMohamed Ahmed
commit c6659e0ffc19b4ef0b3273c185cb8409a154eada upstream. The GSP-RM display code in rm/r535/disp.c owns a handful of direct MMIO routines: the head-timing (vblank) interrupt handler and the per-head vblank enable/disable. They program display registers, not RM, so they belong with the rest of the per-chip register code in engine/disp/. Move them to tu102.c (Turing is the first GSP-capable generation) as tu102_disp_intr() and tu102_head_vblank_get()/put(), exported for rm/r535/disp.c, which keeps calling them by name for now. No functional change. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-2-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSEZhenhao Wan
commit 38a62306c4266bcb3cd89e33c7111ee33096ebb3 upstream. A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSEZhenhao Wan
commit ccf930812f23b8259ef64fd3394d53b093e4651a upstream. In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE opZhenhao Wan
commit 412a6ceb56d501ef2f8202e26ab4b5d4dfbca566 upstream. Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau: Use write-combined maps for coherentFaith Ekstrand
commit 774b73428e6eabb4f0382aeeb76e569c7b106a29 upstream. On Tegra devices, uncached maps translate to device memory, causing unaligned accesses by userspace resulting in a SIGBUS. Instead, use write-combined maps to ensure proper access. This would also affect discrete cards on any Arm device. It was determined that discrete cards regardless of cpu arch should use write-combined maps for coherent anyways. Thus this change is made for all gpu types. Cc: stable@vger.kernel.org Signed-off-by: Faith Ekstrand <faith.ekstrand@collabora.com> Co-developed-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time") Link: https://patch.msgid.link/20260821-tegra-coherent-wc-v2-1-2b1ddb67bf18@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau: unsubscribe the channel-kill event before the fence contextMarek Czernohous
commit 511585987d27d8cb668acebd399fc4deda23404c upstream. nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous <marek@czernohous.de> Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has been killed") Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260812231330.705425-2-mczernohous@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmwareMohamed Ahmed
commit 39fd4b742720c68da8695ee1ffa85c5fea4f8e11 upstream. NVIDIA removed the deprecated actualPclkHz/linkClkFreqHz fields and the whole Legacy{activeCnt, activeFrac, activePolarity, mvidWarEnabled, MvidWarParams} block from the SST sub-struct of NV0073_CTRL_CMD_DP_CONFIG_STREAM_PARAMS between the 535 and 570 releases (compared in OpenRM tags 535.113.01 vs 570.144), shrinking the struct. Everything nouveau writes sits at identical offsets in both layouts except the trailing SST.bEnableAudioOverRightPanel (written as zero), but the size is wrong on r570, which means r535_sor_dp_sst() and r535_sor_dp_vcpi() are sent with an incorrect size. Route the .sst/.vcpi IOR functions through nvkm_rm_api_disp the same way bl_ctrl and dp.get_caps/set_indexed_link_rates already are. Keep the existing implementation for r535 and add an r570 implementation built against the 570.144 layout, which already exists in r570/nvrm/disp.h but was unused until now. Also add the NV0073_CTRL_CMD_DP_CONFIG_STREAM define that was missing from the layout. Other DP controls sent through shared r535 code did not change layout between the tags. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Cc: stable@vger.kernel.org Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260825001408.14219-7-mohamedahmedegypt2001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/dmem: fix mismatched DMA unmap size for large foliosZhenhao Wan
commit caa1bc2a0a6ca19dcb90bbf88208b0fe2decd66f upstream. Device-private THP migration maps migration buffers with page_size() and records that length in dma_info->size. For a compound folio page_size() is PAGE_SIZE << order, but two teardown sites still pass a literal PAGE_SIZE to dma_unmap_page(): - nouveau_dmem_migrate_to_ram() on the success path, and - nouveau_dmem_migrate_copy_one() on the copy-error path. For an order > 0 folio this unmaps less than was mapped, leaking the remainder of the IOMMU/IOVA mapping. The other unmap sites, in nouveau_dmem_migrate_chunk() and nouveau_dmem_evict_chunk(), already use the saved size; use it here too. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com> Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-1-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/nouveau/dmem: fix callocated underflow on large folio splitZhenhao Wan
commit c2256c044a1df39c8aad4dd2d6f709b2533e2d7a upstream. nouveau_dmem_folio_free() drops chunk->callocated once per freed folio, while a large (compound) device-private folio is only counted once when it is allocated. When such a folio is split, the mm core invokes ->folio_split() (nouveau_dmem_folio_split()) once for each new sub-folio, but the hook only fixes up the sub-folio metadata and leaves chunk->callocated unchanged. Each resulting sub-folio is later freed separately, so after a split the single allocation (+1) is met by N frees (-N), leaving chunk->callocated short by N-1. On the first split/free cycle it underflows: WARN_ON(!chunk->callocated) fires, the unsigned counter wraps and never returns to zero, so the chunk can no longer be reclaimed (nouveau_dmem_fini() also warns on the leaked count). Account for the new sub-folio in the split hook, under the same lock as nouveau_dmem_folio_free(), so the count stays balanced. Fixes: c32287471077 ("gpu/drm/nouveau: enable THP support for GPU memory migration") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260811-b4-nouveau-dmem-thp-fixes-v1-2-2cdf9860af2a@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/pagemap: Fix folio allocation fallback and use-after-putMatthew Brost
commit df72e55e754c8d449321ddddad19a8bd3cb8d032 upstream. drm_pagemap_migrate_populate_ram_pfn() had two issues when populating RAM PFNs with higher-order folios: 1. The higher-order vma_alloc_folio()/folio_alloc() calls did not pass __GFP_NOWARN, so a THP allocation failure under memory pressure would spam the kernel log, and there was no fallback path despite a TODO comment stating one was needed. Add __GFP_NOWARN to the higher-order allocation and, on failure, fall back to order-0 allocations for the entire range originally covered by the failed higher-order allocation, leaving MIGRATE_PFN_COMPOUND unset for those PFNs. 2. In the free_pages error path, order was computed via folio_order(page_folio(page)) *after* put_page(page) had already dropped the reference, resulting in a use-after-free/put when that was the last reference on the page. Compute order before releasing the page. Introducing the fallback in 1. also requires the source page array handed to ->copy_to_ram() to be built differently. Both callers only populated the entry at the head of each source folio, relying on the copy callback to derive the rest of the folio from the order recorded in the matching drm_pagemap_addr. Once the destination has been demoted to order-0 folios the drm_pagemap_addr entries are per-page, so a source page is needed for every one of them; leaving them NULL makes the copy callback stop after the first page and the remainder of the range is never copied. The source folio is only split later, by migrate_vma_pages() / migrate_device_pages(), so its order cannot be used to detect the demotion - test the destination for MIGRATE_PFN_COMPOUND instead. Factor the array population out into drm_pagemap_migrate_populate_src_pages() and use it from both drm_pagemap_evict_to_ram() and __drm_pagemap_migrate_to_ram(). Fixes: ddeda6136038 ("drm/pagemap: Allocate folios when possible") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-5 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260902063504.3024362-2-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/sysfb: ofdrm: Fix is_avivo() constant comparison bugShixiong Ou
commit 958f35cbb8955ca3fa439cd9f2092cb42414aa8c upstream. The is_avivo() function has a logic error where it compares a constant to another constant instead of checking the device parameter: (PCI_VENDOR_ID_ATI_R600 >= 0x9400) Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: f496834e1674 ("drm/ofdrm: Add per-model device function") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: <stable@vger.kernel.org> # v6.2+ Link: https://patch.msgid.link/20260731111729.703116-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/sysfb: ofdrm: Fix integer overflow in fb_size calculationShixiong Ou
commit c6f48e59ece0123f6a11527ad4d89b21c2d65b87 upstream. The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers") Cc: <stable@vger.kernel.org> # v6.2+ Link: https://patch.msgid.link/20260825104134.669676-1-oushixiong1025@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/sysfb: simpledrm: Improve stride validationThomas Zimmermann
commit df6533f11688aa30be3bb883c7637f4ffdbb7cbd upstream. Validate the computed stride against the maximum value INT_MAX. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 7bfa5c7b28d6 ("drm/simpledrm: Compute linestride with drm_format_info_min_pitch()") Cc: <stable@vger.kernel.org> # v6.1+ Link: https://patch.msgid.link/20260625094509.157581-5-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/sysfb: simpledrm: Improve panel-size validationThomas Zimmermann
commit 3a75a0761914d01c7362adf1f906cc1d1762c189 upstream. Validate the panel size from the device-tree node against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail transparently on errors; do not warn. v3: - move comments to a more prominent place (Thierry) v2: - only use initialized values in debugging output (Sashiko) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 2a6d731a8f16 ("drm/simpledrm: Allow physical width and height configuration via panel node") Cc: Rayyan Ansari <rayyan@ansari.sh> Cc: <stable@vger.kernel.org> # v6.4+ Link: https://patch.msgid.link/20260625094509.157581-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/sysfb: simpledrm: Improve framebuffer-size validationThomas Zimmermann
commit 03f1a3545b721fa7fdadd00080e237519a286a97 upstream. Validate the framebuffer size from the firmware against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail probing on errors. v2: - remove unused function simplefb_get_validated_int0() (Sashiko) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: <stable@vger.kernel.org> # v5.14+ Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Link: https://patch.msgid.link/20260625094509.157581-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: Reject zero-sized AQL queue allocations after size halvingSunday Clement
commit 40ba09e11188d1b7f79d51fc28aca5ea45e0c138 upstream. KFD_IOC_ALLOC_MEMORY_OF_GPU with flag KFD_IOC_ALLOC_MEM_FLAGS_AQL_QUEUE_MEM and size=1 triggers the AQL wraparound workaround (size >>= 1), reducing size to 0. The resulting zero passes through PAGE_ALIGN(0) = 0 without validation, bypassing the per-process VRAM quota check in reserve_mem_limit() (vram_used + 0 > vram_available is always false). The fix adds post-halving zero-size validation in the primary allocation path (amdgpu_amdkfd_gpuvm.c). The check happens after size halving but before reserve_mem_limit(), and uses err_alignment_size error path to properly clean up the allocated kgd_mem structure and mutex. Cc: stable@vger.kernel.org Signed-off-by: Sunday Clement <Sunday.Clement@amd.com> Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: guard against NULL restore_mqd in CRIU queue restoreVladimir Marioukhine
commit 6aa530642f95d5c48aa336416f94a35e7949b647 upstream. Both create_queue_cpsch() and create_queue_nocpsch() unconditionally call mqd_mgr->restore_mqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restore_mqd is not implemented for the given queue type, a user holding CAP_CHECKPOINT_RESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. Note that checkpoint_mqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload. Add a NULL guard for restore_mqd immediately after mqd_mgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpoint_mqd guard in checkpoint_mqd(). Fixes: 48f0bdf4e38e ("drm/amdkfd: Added MQD manager files for GFX12.") Cc: stable@vger.kernel.org Signed-off-by: Vladimir Marioukhine <Vladimir.Marioukhine@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vramXiaogang Chen
commit 520e345ffe05aabef1db82beda4288afb1757ff2 upstream. When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up. Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0. Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: fix scope of mqd_mgr dereference in pqm_debugfs_mqdsMario Limonciello
commit 012a026bae0212952b423a842b7e2c0bf21f8e7a upstream. Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD queue triggers a NULL pointer dereference because the for loop that calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the if (pqn->q) block that initializes mqd_mgr. The queue list can contain entries where pqn->q is NULL (kernel queues where only pqn->kq is valid). In the original code: if (pqn->q) { ... mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type]; size = mqd_mgr->mqd_stride(...); } for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block mqd = q->mqd + size * xcc; r = mqd_mgr->debugfs_show_mqd(m, mqd); } When iterating over a queue node where pqn->q is NULL: 1. The if (pqn->q) block is skipped 2. mqd_mgr remains uninitialized (NULL from declaration) 3. The for loop executes anyway 4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode RIP: 0010:0x0 Call Trace: pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu] kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu] seq_read_iter+0x132/0x4b0 ... Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr and related variables are only used when properly initialized. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: Fix error path at svm_migrate_copy_to_ramXiaogang Chen
commit 960c4a8069bfd352c48cc88592618f1ebe24c69e upstream. If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general. The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path. Cc: stable@vger.kernel.org Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdkfd: Add TLB flush after MES queue eviction/suspensionPriya Hosur
commit 94e25cb6ab7f4f025bcdcd8ea79fda30f12843a4 upstream. MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration. The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed. Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier) This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated. Signed-off-by: Priya Hosur <Priya.Hosur@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFTSunil Khatri
commit d6e16df7df4d2c39e2b04b355d0434fb90e2d62c upstream. For different address types the variable PAGE_SHIFT might not work well and it's better to use the GPU specific one Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3494b77d10375e0f9ab784e9b20763339844b55b) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdgpu: update the fw version for gfx12 userqueuesSunil Khatri
commit 49a74a2388528c1a2e96f01114c4513e635605fe upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 69fa36e3ac92f2544ee7a1b719ec212b8247a2da) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdgpu: update the fw version for gfx11 userqueuesSunil Khatri
commit c748dd03df33360549ad60cdccee13570e9c0f90 upstream. Update to the latest stable fw versions where userqueues is working as it is expected with major fixes. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d50201b891604ab97f305d4a20d888ba93305b48) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
19 hoursdrm/amdgpu: Skip accessing psp rum time db for APUsKanala Ramalingeswara Reddy
commit a26301203a196a991527f7b1ab884d4dd0e7c95e upstream. Psp runtime DB is for dGPUs only. Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit dce8195027f146467c9378efb2bb1b0859cb735e) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-12 05:16:06 +0000