summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-30clk: qcom: qcm2290: Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCsImran Shaik2-3/+3
Add RETAIN_FF_ENABLE flag for DISPCC and GPUCC GDSCs on QCM2290 to retain the register context across GDSC power collapse. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-6-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: qcm2290: Set POLL_CFG_GDSCR flag for DISPCC and GPUCC GDSCsImran Shaik2-2/+2
The Qualcomm QCM2290 SoC GDSCR status bit may not reflect the actual state of the GDSC, instead the power on/off bits in CFG_GDSCR must be polled to determine the GDSC state correctly. Set POLL_CFG_GDSCR flag for the QCM2290 MDSS GDSC and GPUCC GX GDSC to ensure the correct GDSC status. This is not applicable for GPUCC CX GDSC, which relies on gds_hw_ctrl status. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Fixes: 8cab033628b1 ("clk: qcom: Add QCM2290 GPU clock controller driver") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-5-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: dispcc-qcm2290: Enable runtime PM supportImran Shaik1-0/+1
The QCM2290 DISPCC is now associated with a power domain (RPMPD_CX) to propagate genpd performance state votes to the CX rail. Set use_rpm to true so that a runtime PM reference is acquired and released around probe, instead of leaving a permanent 'enable' vote on the power domain. Fixes: cc517ea3333f ("clk: qcom: Add display clock controller driver for QCM2290") Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-4-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: dispcc-qcm2290: Move to the latest common qcom_cc_probe() modelImran Shaik1-19/+19
Update the QCM2290 DISPCC driver to use the qcom_cc_probe() model by moving the critical clocks handling and PLL configurations from probe to the driver_data to align with the latest convention. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-3-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probeImran Shaik1-98/+15
Some GCC branch clocks are required to be kept always-on due to the hardware requirements. Drop the modelling of those always-on QCM2290 GCC clocks and use the latest .clk_cbcr convention to keep them enabled from probe. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-2-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom,qcm2290-dispcc: Add missing power-domains propertyImran Shaik1-0/+7
Add the missing power-domains property to associate DISPCC with RPMPD_CX. This is to ensure the genpd performance state votes on the GDSC to get propagated to the CX rail and to avoid the rail under-voltage conditions. This change breaks ABI, as the power-domains property is marked as required. Fixes: 85cedb4e0c9d ("dt-bindings: clock: Add qualcomm QCM2290 DISPCC bindings") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260718-shikra-dispcc-gpucc-v6-1-62703e05ef0f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoCImran Shaik3-0/+821
Add support for Audio Core Clock Controller (AUDIOCORECC) and Audio Core CSR resets on Qualcomm Shikra SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-shikra-audiocorecc-v4-2-0a89bb13d817@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Add Qualcomm Shikra AudioCoreCC and AudioCoreCSRImran Shaik3-0/+146
Add device tree bindings for the Audio Core Clock Controller (AudioCoreCC) that provides clocks and Audio Core CSR that provides resets on Qualcomm Shikra SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-shikra-audiocorecc-v4-1-0a89bb13d817@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gpucc: Add Nord graphics clock controller supportTaniya Das4-0/+1150
Add support for the GPU clock controllers (GPUCC) on the Qualcomm Nord platform. The platform includes two GPU clock controller instances,GPUCC and GPU2CC. Register support for both controllers, which provide clocks required for the graphics subsystem. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-6-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Document Nord GPU clock controllersTaniya Das3-0/+99
Add Device Tree binding documentation for the GPU clock controllers on the Qualcomm Nord platform. The platform includes two GPU clock controller instances, GPUCC and GPU2CC. Document the compatible strings for both controllers. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-5-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Add Nord display clock controller supportTaniya Das4-0/+4020
Add support for the display clock controllers (DISPCC) on the Qualcomm Nord platform. The platform includes two display clock controller instances, display0 and display1. Register support for both controllers. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-4-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: clock: qcom: Document Nord display clock controllerTaniya Das2-0/+118
Add Device Tree binding documentation for the display clock controller on the Qualcomm Nord SoC. The Nord platform contains two instances of the display clock controller, DISPCC_0 and DISPCC_1. Update the bindings to include compatible strings for both instances. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-3-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: negcc-nord: keep GPU2 CFG clock enabled via critical CBCRTaniya Das1-16/+6
The GPU2 CFG clock must remain enabled for correct operation and should not be exposed as a controllable clk_branch. Remove the clk_branch and mark its CBCR as critical instead to prevent unintended gating. This follows the same approach as 'nw_gcc_gpu_cfg_ahb_clk' and aligns with other always-on clocks in Qualcomm CC drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-2-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: gcc-nord: mark PCIe link clocks as criticalTaniya Das1-30/+7
The PCIe link AHB and XO clocks must remain enabled for proper operation. Representing them as clk_branch instances allows them to be gated, which is undesirable. Remove their clk_branch definitions and register their CBCRs as critical clocks instead so they remain enabled. This matches the handling of similar always-on clocks in other Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-nords_mm_v1-v3-1-32b45232217f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: clean-up simple provider misuse of the consumer APIJerome Brunet4-6/+6
Clock provider should not be using the consumer interface. In other words, a provider should not be dealing with struct clk. This change targets occurrences for which the provider uses the consumer interface and corresponding clk_hw interface exist. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724-clk-provider-simple-clean-v2-2-56f306156d25@baylibre.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: negcc-nord: use clk_regmap_phy_mux for USB3 pipe clock srcsTaniya Das1-37/+12
ne_gcc_usb3_prim_phy_pipe_clk_src and ne_gcc_usb3_sec_phy_pipe_clk_src are 2-bit muxes selecting between a PHY-sourced USB3 pipe clock and BI_TCXO, implemented with clk_regmap_mux_closest_ops. This requires manual parent switching and does not park the mux on the reference clock when the clock is disabled. Convert both to clk_regmap_phy_mux with clk_regmap_phy_mux_ops, which automatically parks the mux on the XO/ref source on disable and restores the PHY parent on enable, matching the existing UFS symbol clock conversions in this driver. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-2-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: nord: use BRANCH_HALT_SKIP for PHY pipe clocksTaniya Das2-6/+6
The PCIe and USB3 pipe clocks on Nord are sourced from their respective PHYs. The halt bit for these branches does not toggle reliably when the PHY is powered down or not yet brought up, so polling for it with BRANCH_HALT_VOTED can spuriously time out. Switch these pipe clock branches to BRANCH_HALT_SKIP, matching the convention used for PHY-sourced pipe clocks elsewhere in the Qualcomm clock drivers. Fixes: a4f780cd5c7a ("clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC") Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260716-b4-nord-pipe-clk-fixes-v1-1-e4f583633356@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLsImran Shaik3-9/+9
CLK_ALPHA_PLL_TYPE_DEFAULT_EVO type PLLs do not have the PLL_TEST_CTL_U1 register, so clk_alpha_pll_configure() does not program test_ctl_hi1_val for this PLL type. The GCC PLL configurations for QCM2290, Shikra and SM6115 wrongly use test_ctl_hi1_val instead of test_ctl_hi_val, deviating from the hardware recommended settings. Fix them to use test_ctl_hi_val. Fixes: 496d1a13d405 ("clk: qcom: Add Global Clock Controller driver for QCM2290") Fixes: 01cf3e27824d ("clk: qcom: Add Global clock controller support on Qualcomm Shikra SoC") Fixes: e88c533d8a2a ("clk: qcom: gcc-sm6115: Add missing PLL config properties") Cc: stable@vger.kernel.org Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260729-pll-test-ctrl-fixup-v1-1-246d79589380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: soc: qcom,aoss-qmp: Document Nord AOSS side channelShawn Guo1-0/+1
Document Always-on Subsystem side channel on Qualcomm Nord SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260729023508.879752-2-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Drop unused dtb_mem_region fieldMukesh Ojha1-1/+2
dtb_mem_region is no longer referenced after the ioremap was moved to respective places where mapping is required. Remove it from struct qcom_pas. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-6-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Map/unmap subsystem region before auth_and_resetMukesh Ojha4-19/+47
Qualcomm remoteproc drivers such as qcom_q6v5_mss, which do not use the Peripheral Authentication Service (PAS), always map the MBA region before use and unmap it once the usage is complete. This behavior was introduced to avoid issues seen in the past where speculative accesses from the application processor to the MBA region after it was assigned to the remote Q6 led to an XPU violation. The issue was mitigated by unmapping the region before handing control to the remote Q6. Currently, most Qualcomm SoCs using the PAS driver run either with a standalone QHEE or the Gunyah hypervisor. In these environments, the hypervisor unmaps the Q6 memory from HLOS Stage-2 and remaps it into the Q6 Stage-2 page table. As a result, speculative accesses from HLOS cannot reach the region even if it remains mapped in HLOS Stage-1; therefore, XPU violations cannot occur. However, when the same SoC runs Linux at EL2, Linux itself must perform the unmapping to avoid such issues. It is still correct to apply this mapping/ unmapping sequence even for SoCs that run under Gunyah, so this behavior should not be conditional. Introduce qcom_pas_ctx_map() in qcom_pas.h to centralise the ioremap_wc pattern used by both qcom_q6v5_pas and qcom_mdt_pas_load, and use it in both places. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-5-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Fix the PAS context creation placementMukesh Ojha1-16/+13
DTB PAS context creation should be done only for subsystems that support a DTB firmware binary; otherwise, memory is wasted. Move the context creation to the appropriate location. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 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-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id checkMukesh Ojha1-8/+5
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>
2026-07-30remoteproc: qcom: annotate mem_region fields with __iomemMukesh Ojha3-11/+11
The firmware memory regions in qcom_adsp, qcom_pas and qcom_wcnss are mapped using devm_ioremap_wc() / devm_ioremap_resource_wc(), which return void __iomem *. However, the mem_region (and dtb_mem_region) fields in the respective driver structs were declared as plain void *, causing sparse to flag address space mismatches: qcom_q6v5_adsp.c:639:26: warning: incorrect type in assignment (different address spaces) qcom_q6v5_adsp.c:639:26: expected void *mem_region qcom_q6v5_adsp.c:639:26: got void [noderef] __iomem * qcom_q6v5_pas.c:141:45: warning: incorrect type in argument 2 (different address spaces) qcom_q6v5_pas.c:141:45: expected void const volatile [noderef] __iomem *src qcom_q6v5_pas.c:141:45: got void * qcom_q6v5_pas.c:637:25: warning: incorrect type in assignment (different address spaces) qcom_q6v5_pas.c:637:25: expected void *mem_region qcom_q6v5_pas.c:637:25: got void [noderef] __iomem * qcom_q6v5_pas.c:654:29: warning: incorrect type in assignment (different address spaces) qcom_q6v5_pas.c:654:29: expected void *dtb_mem_region qcom_q6v5_pas.c:654:29: got void [noderef] __iomem * qcom_wcnss.c:540:27: warning: incorrect type in assignment (different address spaces) qcom_wcnss.c:540:27: expected void *mem_region qcom_wcnss.c:540:27: got void [noderef] __iomem * Fix this by annotating the struct fields with __iomem to correctly reflect the address space of the underlying mapping. These regions are subsequently passed to qcom_mdt_load(), qcom_mdt_load_no_init() and qcom_mdt_pas_load(), all of which take void * and use plain memcpy()/memset() internally to write firmware segments into the region. This is intentional and safe: the mappings are write-combining (WC), which on arm64 permits bulk CPU stores without requiring the memcpy_toio()/memset_io() accessors. Changing the MDT loader API to accept void __iomem * would be a more invasive change and would affect callers. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260724182858.1868271-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30arm64: dts: qcom: eliza: Add fallback compatible for ADSP remoteprocAbel Vesa1-1/+1
The ADSP found on Eliza SoC is actually fully compatible with the ones from SM8750 class. So add the SM8550 compatible as fallback, just like the rest from the SM8750 class SoCs. Fixes: 88ddafb01ec0 ("arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-2-e1e98ae15533@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30dt-bindings: remoteproc: qcom,milos-pas: Move Eliza ADSP to SM8550 schemaAbel Vesa2-3/+2
The ADSP PAS found on Eliza SoC looks fully compatible with SM8750, which can fallback to SM8550 except for the extra interrupt ("shutdown-ack"). So document its bindings in the SM8550 schema instead. Fixes: 7cf2f07f949c ("dt-bindings: remoteproc: qcom,milos-pas: Document Eliza ADSP") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-1-e1e98ae15533@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-30tools/mm/page_owner_sort: bound pattern output copiesYichong Chen1-6/+21
search_pattern() copies a regex capture into caller-provided buffers without knowing their sizes. Several callers pass fixed-size buffers, including FIELD_BUFF and TASK_COMM_LEN. Pass the destination size to search_pattern(), reject captures that do not fit before copying them, and terminate the output string inside search_pattern(). Link: https://lore.kernel.org/20260629014316.130307-4-chenyichong@uniontech.com Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Cc: Vishal Moola <vishal.moola@gmail.com> Cc: Ye Liu <ye.liu@linux.dev> Cc: Zhen Ni <zhen.ni@easystack.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30tools/mm/page_owner_sort: free per-record allocationsYichong Chen1-2/+18
add_list() allocates comm and txt for each page owner record, but the cleanup path only frees the outer list array. This leaks both buffers for every retained record. Free partial allocations in add_list(), discarded records during culling, and retained records on exit. Link: https://lore.kernel.org/20260629014316.130307-3-chenyichong@uniontech.com Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Reviewed-by: Vishal Moola <vishal.moola@gmail.com> Cc: Ye Liu <ye.liu@linux.dev> Cc: Zhen Ni <zhen.ni@easystack.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30tools/mm/page_owner_sort: return explicit filter resultsYichong Chen1-9/+31
Patch series "tools/mm/page_owner_sort: fix filtering and cleanup issues", v5. Patch 1 renames is_need() to filter_record() and makes the filter path return explicit results. Patch 2 fixes the per-record allocation leaks. Patch 3 bounds search_pattern() output copies, addressing the pre-existing issue reported by Sashiko/AI review. This patch (of 3): Rename is_need() to filter_record() and make the filter path return explicit error, skip, and match results. This lets callers distinguish allocation failures from records that simply do not match active filters. Link: https://lore.kernel.org/20260629014316.130307-1-chenyichong@uniontech.com Link: https://lore.kernel.org/20260629014316.130307-2-chenyichong@uniontech.com Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Reviewed-by: Vishal Moola <vishal.moola@gmail.com> Cc: Ye Liu <ye.liu@linux.dev> Cc: Zhen Ni <zhen.ni@easystack.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: nommu: add sysctl_max_map_count() check for do_mmap()Hajime Tazaki1-0/+3
The sysctl variable vm.max_map_count (sysctl_max_map_count) is not exposed under !MMU configurations, but its default value (DEFAULT_MAX_MAP_COUNT) is still used as a allocation limit. Currently, this limit is enforced when a VMA entry is split into two chunks (split_vma()), but it is not checked during initial allocation (do_mmap()). As a result, if a user requests a large number of memory allocations, the system will continue allocating until it hits an Out-Of-Memory (OOM) condition. This commit introduces a check at the beginning of do_mmap() in nommu.c to prevent this situation. This issue was detected using the Linux Test Project (LTP) test linked below. Link: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/munmap/munmap04.c Link: https://lore.kernel.org/20260702012830.667205-1-thehajime@gmail.com Signed-off-by: Hajime Tazaki <thehajime@gmail.com> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: memcg: reset oom_group in css_resetJiayuan Chen1-0/+1
memory.oom.group defaults to disabled, but css_reset did not clear memcg->oom_group when a disabled memory css is kept alive by another controller dependency. Reset it with the other memory controller policies so a hidden memcg cannot keep applying stale group OOM kill policy. Link: https://lore.kernel.org/20260703063826.306878-2-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Acked-by: Roman Gushchin <roman.gushchin@linux.dev> Reviewed-by: Muchun Song <muchun.song@linux.dev> Cc: Jiayuan Chen <jiayuan.chen@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: memcg: reset zswap settings in css_resetJiayuan Chen1-0/+4
mem_cgroup_css_reset() is called when the memory controller is disabled on a cgroup but the memcg cannot be destroyed because it is pinned by a subsystem dependency -- for example, the io controller declares .depends_on = 1 << memory_cgrp_id, so memory remains in the cgroup_ss_mask and the css is hidden rather than killed. The purpose of css_reset is to revert the memcg to its vanilla state so that no policies are applied and the css can be safely made visible again later. Currently, all page counters (memory.max, swap.max, kmem.max, tcpmem.max) and other limits (soft_limit, memory.high, swap.high) are reset to their defaults, but zswap_max and zswap_writeback are not. These fields are initialized in css_alloc (zswap_max = PAGE_COUNTER_MAX, zswap_writeback inherited from parent) but were missing from css_reset. As a result, stale zswap policies remain in effect after css_reset: the zswap charge path (obj_cgroup_may_zswap) continues to enforce the old zswap_max limit, and the writeback path continues to honor the old zswap_writeback setting, even though the memory controller has been "disabled" on this cgroup. Reset zswap_max to PAGE_COUNTER_MAX and zswap_writeback to true, matching their defaults in css_alloc. Test: echo "+memory +io" > /sys/fs/cgroup/cgroup.subtree_control mkdir /sys/fs/cgroup/test mkdir /sys/fs/cgroup/test/child echo "+memory +io" > /sys/fs/cgroup/test/cgroup.subtree_control echo 10000 > /sys/fs/cgroup/test/child/memory.zswap.max # child/memory.swap.max and child/memory.zswam.max disappear echo "-memory" > /sys/fs/cgroup/test/cgroup.subtree_control # re-enable memory control echo "+memory" > /sys/fs/cgroup/test/cgroup.subtree_control # before this patch cat /sys/fs/cgroup/test/child/memory.zswap.max 8192 # after this patch, same as memory.swap.max cat /sys/fs/cgroup/test/child/memory.zswap.max max Link: https://lore.kernel.org/20260703063826.306878-1-jiayuan.chen@linux.dev Link: https://lore.kernel.org/20260702024827.353185-1-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Reviewed-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Muchun Song <muchun.song@linux.dev> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30MAINTAINERS: add ABI docs and selftests to ZRAM entryZenghui Yu (Huawei)1-0/+3
Ensure updates to these files get sent to the right place. Link: https://lore.kernel.org/20260702085655.51858-1-zenghui.yu@linux.dev Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Acked-by: SJ Park <sj@kernel.org> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/sysfs: remove region size validationSJ Park1-3/+0
DAMON_SYSFS validates user inputs for monitoring target regions to disallow negative size regions. DAMON core assumes only positive size regions, though. The validation is incomplete. Fortunately damon_set_regions(), which is eventually used by DAMON_SYSFS, does the complete validation. Remove the incomplete and unnecessary validation. Link: https://lore.kernel.org/20260705155600.96555-9-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: remove start, end check in damon_set_region_system_rams()SJ Park1-3/+0
damon_set_region_system_rams() validates user inputs to avoid creating a negative size region. But DAMON core avoids zero size, too. The check is incomplete. The complete check is done inside damon_set_regions(), which is eventually called from damon_set_region_system_rams_default(). Drop the incomplete and unnecessary check. Link: https://lore.kernel.org/20260705155600.96555-8-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon: document region size validation in damon_set_regions()SJ Park1-1/+2
The kernel doc comment of damon_region clearly specifies every region should have positive size. But it is unclear who should verify it. damon_set_regions() is the recommended DAMON core function for setting regions from the callers, and has the verification. Update the comment to clarify the callers should be ok to pass any values for region addresses, as long as they use damon_set_regions(). Link: https://lore.kernel.org/20260705155600.96555-7-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/lru_sort: remove duplicated min_region_sz power_of_2() checkSJ Park1-5/+0
DAMON_LRU_SORT validates the user input for min_region_sz. The same validation is done inside damon_start() and damon_commit_ctx(). Remove the unnecessary duplicate. Link: https://lore.kernel.org/20260705155600.96555-6-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/reclaim: remove duplicated min_region_sz power of 2 checkSJ Park1-5/+0
DAMON_RECLAIM validates the user input for min_region_sz. The same validation is done inside damon_start() and damon_commit_ctx(). Remove the duplicate. Link: https://lore.kernel.org/20260705155600.96555-5-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/sysfs: remove duplicated commit input validity checkSJ Park1-31/+1
DAMON sysfs interface does parameters validation-purpose damon_commit_ctx() calls for parameters update. Now the same logic is embedded inside damon_commit_ctx() itself. Hence, the validation in DAMON sysfs interface is just an unnecessary duplicate. Remove it. Link: https://lore.kernel.org/20260705155600.96555-4-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: do parameter testing commit on damon_start()SJ Park1-2/+12
damon_start() and damon_commit_ctx() are two main DAMON core API functions for setting whole DAMON parameters. While damon_commit_ctx() does holistic parameters testing, damon_start() just believes the caller validated the whole thing. Embed the holistic parameter check that is already in damon_commit_ctx() into damon_start(). After this change, the callers can safely call damon_start() without validating the parameters. Link: https://lore.kernel.org/20260705155600.96555-3-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/damon/core: safely validate src on damon_commit_ctx()SJ Park1-14/+47
Patch series "mm/damon: validate all parameters in the core". DAMON has a number of parameters. Some of the parameters are validated by DAMON, while some are validated by DAMON API callers. Each caller has their own set of parameters that are exposed to users. Hence each caller has their own ways to do the validation. There is no clear lines for the responsibilities. It is confusing and easy to make mistakes at validations. Actually we found a few bugs in the class. Define DAMON core as the place to do all the validations and implement those. damon_set_regions(), damon_start() and damon_commit_ctx() are the three main DAMON core API functions for setup of DAMON parameters. Make the three functions to do safe and holistic parameter checks. The first one is already providing the validation, so changes are only for the last two functions. This might add unnecessary validations for some use cases. The overhead should be negligible as parameters update is expected to only rarely happen. It reduces the number of places to check and fix for bugs of the class from all callers to the single component. The maintenance efficiency gain is obvious. Further cleanup documents and caller code. Make the lines of validation duties clearer. Remove validations that are no more needed owing to the core validations. Patches Sequence ================ Patch 1 implements the core holistic parameters validation for damon_commit_ctx(). Patch 2 extends the validation to damon_start(). Patch 3 removes the duplicated holistic parameters validation in DAMON sysfs interface, which is now embedded into the core layer. Patches 4 and 5 remove duplicated min_region_sz validation in DAMON modules. Patches 6 updates kernel doc to clarify damon_set_regions() is doing the range validation. Patches 7 and 8 remove monitoring target range validations that doesn't necessary thanks to the validation in damon_set_regions(). This patch (of 8): damon_commit_ctx() does its holistic parameter set validation while applying the new parameter in the set one by one. If it finds a parameter is invalid, because some invalid parameters may already be committed (it is called "commit" but not atomic and irreversable), it stops the running DAMON context. The callers of the function therefore have to validate the parameters before calling it. Because the function already embeds holistic validation, DAMON_SYSFS reuses it in a safe way. It creates a test-purpose context that is not running but mimics the running one, and calls damon_commit_ctx() against the test purpose context. If it succeeds, the parameters are considered valid, and a real damon_commit_ctx() call against the running context is made with those. Other callers such as DAMON_RECLAIM and DAMON_LRU_SORT do not expose full parameters to users. For efficiency, they validate only the known set of parameters. The efficiency gain is arguably small and doubtful, though. Meanwhile the maintenance overhead of the multiple different validations is clearly high. We actually found and fixed a few bugs in the class. Update damon_commit_ctx() to embed DAMON_SYSFS' safe and holistic validation approach. Callers can simply call damon_commit_ctx() without worrying if their parameters are invalid. Note that damon_commit_ctx() can still cause an unexpected stop of the running context, if internal memory allocation fails. It is arguably unlikely since those internal allocations are too small to fail, but theoretically possible. It should also be better addressed, but not necessarily a blocker of this small and incremental improvement effort. Link: https://lore.kernel.org/20260705155600.96555-1-sj@kernel.org Link: https://lore.kernel.org/20260705155600.96555-2-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30docs: ABI: zram: fix spelling mistakesArukonda Rahul1-3/+3
Fix spelling mistakes in the zram sysfs ABI documentation. Link: https://lore.kernel.org/20260707165131.4408-1-rahularukonda2@gmail.com Signed-off-by: Arukonda Rahul <rahularukonda2@gmail.com> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Richard Chang <richardycc@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/mprotect: use huge_ptep_get() for hugetlbDev Jain1-3/+9
prot_none_hugetlb_entry() is the hugetlb callback for the early mprotect(PROT_NONE) PFN permission walk on x86. The callback passes the decoded PFN to pfn_modify_allowed(). For a hugetlb callback, the pte pointer refers to a hugetlb entry. On architectures where hugetlb entries need huge_ptep_get(), reading that entry with ptep_get() can make the permission check use the wrong PFN. Use huge_ptep_get() before decoding the hugetlb PFN. Currently there is no path which can trigger a bug: huge_ptep_get() is a simple ptep_get() for x86, and the prot_none walk occurs only for x86. So no need to backport - use the correct helper anyways. [akpm@linux-foundation.org: s/EACCESS/EACCES/] Link: https://lore.kernel.org/20260703114202.365553-7-dev.jain@arm.com Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings") Signed-off-by: Dev Jain <dev.jain@arm.com> Reviewed-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/page_vma_mapped: use huge_ptep_get() for hugetlbDev Jain1-1/+7
check_pte() is the final validation step in page_vma_mapped_walk(). It reads pvmw->pte with ptep_get() to decide whether the entry maps the PFN range being walked. For hugetlb VMAs, that pointer refers to a hugetlb entry. On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-6-dev.jain@arm.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Dev Jain <dev.jain@arm.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Muchun Song <muchun.song@linux.dev> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/migrate: use huge_ptep_get() in remove_migration_pte()Dev Jain1-1/+5
remove_migration_pte() converts migration entries back to present PTEs after folio migration completes. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-5-dev.jain@arm.com Fixes: 290408d4a250 ("hugetlb: hugepage migration core") Signed-off-by: Dev Jain <dev.jain@arm.com> Acked-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/rmap: use huge_ptep_get() in try_to_migrate_one()Dev Jain1-6/+9
try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Use huge_ptep_get() to dereference a huge pte pointer. Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one. [akpm@linux-foundation.org: coding-style cleanups] Link: https://lore.kernel.org/20260703114202.365553-4-dev.jain@arm.com Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function") Signed-off-by: Dev Jain <dev.jain@arm.com> Acked-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/rmap: use huge_ptep_get() in try_to_unmap_one()Dev Jain2-6/+12
Patch series "Fix incorrect access of hugetlb pte entries", v3. There are various places which use ptep_get() to get the pte entry corresponding to a hugetlb folio. Some arches (like s390) have special handling to compute the pteval, so they provide huge_ptep_get(). Use this helper consistently. Additionally, some code paths may provide huge_ptep_get with an unaligned address. This is a problem on arm64 (I checked other arches and it looks fine for them), which is fixed in patch 1. The fix is made to be backport-friendly: the cleaner fix would be to perhaps pass the hstate to huge_ptep_get() - that is wider churn and we can do that later. This patch (of 5): try_to_unmap_one() handles hugetlb folios when memory failure needs to replace a poisoned hugetlb mapping with a hwpoison entry. In that case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads it with ptep_get(). On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave. It is not clear whether this has a trivially visible effect to userspace. Just use huge_ptep_get() for dereferencing a huge pte pointer. Link: https://lore.kernel.org/20260703114202.365553-1-dev.jain@arm.com Link: https://lore.kernel.org/20260703114202.365553-3-dev.jain@arm.com Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()") Signed-off-by: Dev Jain <dev.jain@arm.com> Reported-by: David Hildenbrand <david@kernel.org> Reviewed-by: Muchun Song <muchun.song@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Byungchul Park <byungchul@sk.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Gregory Price <gourry@gourry.net> Cc: Harry Yoo <harry@kernel.org> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jann Horn <jannh@google.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Jun'ichi "Nick" Nomura <j-nomura@ce.jp.nec.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: factor out can_spin_trylock()Brendan Jackman3-25/+25
Deduplicate checks for whether the current context is safe for spin_trylock(). Does this function really belong in mm/internal.h or is it generic? Not sure. If someone ends up duplicating this logic elsewhere in the kernel, that would be a shame. But if it goes in some generic header, someone treats it as documentation about where it's guaranteed safe to spin_trylock(), and then it emerges that there are other subtle preconditions that didn't affect the mm usecase, that would be worse. So, just be conservative and keep it local. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-18-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Suggested-by: Harry Yoo <harry@kernel.org> Link: https://lore.kernel.org/all/397859cb-b127-4cc6-9c71-044afc99bf0c@kernel.org/ Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm/page_alloc: drop alloc_flags arg from alloc_flags_cma()Brendan Jackman1-7/+6
To align the style with other alloc_flags_*() functions, drop this additive argument and just have the callers do that themselves. Note you can't always freely or alloc_flags like these callers do (because of the WMARK bits that encode an enum) but this is fine for ALLOC_CMA, just like it's fine for e.g. ALLOC_NON_BLOCK returned by alloc_flags_nonblocking() and or'd by its caller. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-17-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Link: https://lore.kernel.org/all/5dcdd1ef-21ad-4ed0-9e8a-0e5cf96b4392@kernel.org/ Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30mm: remove the __GFP_NO_OBJ_EXT flagVlastimil Babka (SUSE)3-23/+1
All users of the flag are converted to SLAB_ALLOC_NO_RECURSE or ALLOC_NO_CODETAG (from __GFP_NO_CODETAG which reused the NO_OBJ_EXT bit). Free up the flag bit. [Rebased onto __GFP_NO_CODETAG removal] Link: https://lore.kernel.org/20260703-alloc-trylock-v5-16-c87b714e19d3@google.com Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Brendan Jackman <jackmanb@google.com> Acked-by: Hao Ge <hao.ge@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 09:58:52 +0000