- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 5.4 01/22] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 7f0a63628c43a..eac329fe27902 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2901,8 +2901,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
21
0 0

[PATCH AUTOSEL 5.10 01/34] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 79c52c7a02e3a..d447b2416b98b 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2896,8 +2896,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
33
0 0

[PATCH AUTOSEL 5.15 01/43] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 6a8dadea40f92..79074d22959b9 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2897,8 +2897,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
42
0 0

[PATCH AUTOSEL 6.1 01/58] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 204b246f0e3f9..0219f1175c078 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2873,8 +2873,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
57
0 0

[PATCH AUTOSEL 6.6 01/66] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 34f9211b26793..80316297374cc 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2860,8 +2860,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
65
0 0

[PATCH AUTOSEL 6.12 01/93] drm/amd/display: disable DPP RCG before DPP CLK enable

by Sasha Levin

From: Charlene Liu <Charlene.Liu(a)amd.com> [ Upstream commit 1bcd679209420305a86833bc357d50021909edaf ] [why] DPP CLK enable needs to disable DPPCLK RCG first. The DPPCLK_en in dccg should always be enabled when the corresponding pipe is enabled. Reviewed-by: Hansen Dsouza <hansen.dsouza(a)amd.com> Signed-off-by: Charlene Liu <Charlene.Liu(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of both the commit message and code changes, my answer is: **YES** This commit should be backported to stable kernel trees for the following reasons: ## Critical Hardware Sequencing Fix The commit addresses a fundamental hardware sequencing requirement where DPP (Display Pipes and Planes) Root Clock Gating (RCG) must be disabled before enabling the DPP clock. This is a critical timing constraint that, if violated, can cause severe system issues. ## Specific Code Evidence 1. **In `dccg35_update_dpp_dto()`**, the fix adds a crucial sequencing step: ```c + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, phase, DPPCLK0_DTO_MODULO, modulo); dcn35_set_dppclk_enable(dccg, dpp_inst, true); ``` This ensures RCG is disabled (false) before enabling the DPP clock. 2. **In `dcn35_enable_plane()`**, explicit clock control is added: ```c + /*make sure DPPCLK is on*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, true); + dpp->funcs->dpp_dppclk_control(dpp, false, true); ``` 3. **Removal of problematic init code** in `dcn35_init_hw()`: ```c - if (res_pool->dccg->funcs->dccg_root_gate_disable_control) { - for (i = 0; i < res_pool->pipe_count; i++) - res_pool->dccg->funcs->dccg_root_gate_disable_control(res_pool->dccg, i, 0); - } ``` ## Similarity to Previous Critical Fixes This commit follows the pattern of Similar Commit #1, which also addressed clock gating sequencing issues that could cause system hangs. The commit message explicitly states this is needed because "DPP CLK enable needs to disable DPPCLK RCG first." ## Impact and Risk Assessment - **Bug Fixed**: Incorrect clock sequencing that can cause system instability - **Scope**: Limited to DCN35 display hardware (recent AMD GPUs) - **Complexity**: Small, focused changes with clear purpose - **Risk**: Low risk of regression - adds proper sequencing without major architectural changes This fix meets all criteria for stable backporting: - Fixes a real bug affecting users (system stability) - Small and contained changes - No new features or architectural changes - Addresses hardware constraints that cannot be worked around The commit should be backported to all stable kernels that include DCN35 display support to ensure proper display functionality and system stability for users with affected AMD GPUs. .../amd/display/dc/dccg/dcn35/dcn35_dccg.c | 38 ++++++++++++------- .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 21 ++++++---- 2 files changed, 38 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c b/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c index b363f5360818d..ad910065f463f 100644 --- a/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c +++ b/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c @@ -391,6 +391,7 @@ static void dccg35_set_dppclk_rcg(struct dccg *dccg, struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg); + if (!dccg->ctx->dc->debug.root_clock_optimization.bits.dpp && enable) return; @@ -411,6 +412,8 @@ static void dccg35_set_dppclk_rcg(struct dccg *dccg, BREAK_TO_DEBUGGER(); break; } + //DC_LOG_DEBUG("%s: inst(%d) DPPCLK rcg_disable: %d\n", __func__, inst, enable ? 0 : 1); + } static void dccg35_set_dpstreamclk_rcg( @@ -1112,30 +1115,24 @@ static void dcn35_set_dppclk_enable(struct dccg *dccg, { struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg); + switch (dpp_inst) { case 0: REG_UPDATE(DPPCLK_CTRL, DPPCLK0_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK0_ROOT_GATE_DISABLE, enable); break; case 1: REG_UPDATE(DPPCLK_CTRL, DPPCLK1_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK1_ROOT_GATE_DISABLE, enable); break; case 2: REG_UPDATE(DPPCLK_CTRL, DPPCLK2_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK2_ROOT_GATE_DISABLE, enable); break; case 3: REG_UPDATE(DPPCLK_CTRL, DPPCLK3_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK3_ROOT_GATE_DISABLE, enable); break; default: break; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) DPPCLK_EN = %d\n", __func__, dpp_inst, enable); } @@ -1163,14 +1160,18 @@ static void dccg35_update_dpp_dto(struct dccg *dccg, int dpp_inst, ASSERT(false); phase = 0xff; } + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, phase, DPPCLK0_DTO_MODULO, modulo); dcn35_set_dppclk_enable(dccg, dpp_inst, true); - } else + } else { dcn35_set_dppclk_enable(dccg, dpp_inst, false); + /*we have this in hwss: disable_plane*/ + //dccg35_set_dppclk_rcg(dccg, dpp_inst, true); + } dccg->pipe_dppclk_khz[dpp_inst] = req_dppclk; } @@ -1182,6 +1183,7 @@ static void dccg35_set_dppclk_root_clock_gating(struct dccg *dccg, if (!dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) return; + switch (dpp_inst) { case 0: REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK0_ROOT_GATE_DISABLE, enable); @@ -1198,6 +1200,8 @@ static void dccg35_set_dppclk_root_clock_gating(struct dccg *dccg, default: break; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) rcg: %d\n", __func__, dpp_inst, enable); + } static void dccg35_get_pixel_rate_div( @@ -1521,28 +1525,30 @@ static void dccg35_set_physymclk_root_clock_gating( switch (phy_inst) { case 0: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYASYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYASYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 1: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYBSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYBSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 2: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYCSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYCSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 3: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYDSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYDSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 4: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYESYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYESYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; default: BREAK_TO_DEBUGGER(); return; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) PHYESYMCLK_ROOT_GATE_DISABLE:\n", __func__, phy_inst, enable ? 0 : 1); + } static void dccg35_set_physymclk( @@ -1643,6 +1649,8 @@ static void dccg35_dpp_root_clock_control( return; if (clock_on) { + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); + /* turn off the DTO and leave phase/modulo at max */ dcn35_set_dppclk_enable(dccg, dpp_inst, 1); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, @@ -1654,6 +1662,8 @@ static void dccg35_dpp_root_clock_control( REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, 0, DPPCLK0_DTO_MODULO, 1); + /*we have this in hwss: disable_plane*/ + //dccg35_set_dppclk_rcg(dccg, dpp_inst, true); } dccg->dpp_clock_gated[dpp_inst] = !clock_on; diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c index ca446e08f6a27..ff247689dd6d5 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c @@ -241,11 +241,6 @@ void dcn35_init_hw(struct dc *dc) dc->res_pool->hubbub->funcs->allow_self_refresh_control(dc->res_pool->hubbub, !dc->res_pool->hubbub->ctx->dc->debug.disable_stutter); } - if (res_pool->dccg->funcs->dccg_root_gate_disable_control) { - for (i = 0; i < res_pool->pipe_count; i++) - res_pool->dccg->funcs->dccg_root_gate_disable_control(res_pool->dccg, i, 0); - } - for (i = 0; i < res_pool->audio_count; i++) { struct audio *audio = res_pool->audios[i]; @@ -885,12 +880,18 @@ void dcn35_init_pipes(struct dc *dc, struct dc_state *context) void dcn35_enable_plane(struct dc *dc, struct pipe_ctx *pipe_ctx, struct dc_state *context) { + struct dpp *dpp = pipe_ctx->plane_res.dpp; + struct dccg *dccg = dc->res_pool->dccg; + + /* enable DCFCLK current DCHUB */ pipe_ctx->plane_res.hubp->funcs->hubp_clk_cntl(pipe_ctx->plane_res.hubp, true); /* initialize HUBP on power up */ pipe_ctx->plane_res.hubp->funcs->hubp_init(pipe_ctx->plane_res.hubp); - + /*make sure DPPCLK is on*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, true); + dpp->funcs->dpp_dppclk_control(dpp, false, true); /* make sure OPP_PIPE_CLOCK_EN = 1 */ pipe_ctx->stream_res.opp->funcs->opp_pipe_clock_control( pipe_ctx->stream_res.opp, @@ -907,6 +908,7 @@ void dcn35_enable_plane(struct dc *dc, struct pipe_ctx *pipe_ctx, // Program system aperture settings pipe_ctx->plane_res.hubp->funcs->hubp_set_vm_system_aperture_settings(pipe_ctx->plane_res.hubp, &apt); } + //DC_LOG_DEBUG("%s: dpp_inst(%d) =\n", __func__, dpp->inst); if (!pipe_ctx->top_pipe && pipe_ctx->plane_state @@ -922,6 +924,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) { struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; + struct dccg *dccg = dc->res_pool->dccg; + dc->hwss.wait_for_mpcc_disconnect(dc, dc->res_pool, pipe_ctx); @@ -939,7 +943,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) hubp->funcs->hubp_clk_cntl(hubp, false); dpp->funcs->dpp_dppclk_control(dpp, false, false); -/*to do, need to support both case*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, false); + hubp->power_gated = true; hubp->funcs->hubp_reset(hubp); @@ -951,6 +956,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) pipe_ctx->top_pipe = NULL; pipe_ctx->bottom_pipe = NULL; pipe_ctx->plane_state = NULL; + //DC_LOG_DEBUG("%s: dpp_inst(%d)=\n", __func__, dpp->inst); + } void dcn35_disable_plane(struct dc *dc, struct dc_state *state, struct pipe_ctx *pipe_ctx) -- 2.39.5

1 month, 1 week

1
92
0 0

[PATCH AUTOSEL 6.14 001/102] drm/amd/display: disable DPP RCG before DPP CLK enable

by Sasha Levin

From: Charlene Liu <Charlene.Liu(a)amd.com> [ Upstream commit 1bcd679209420305a86833bc357d50021909edaf ] [why] DPP CLK enable needs to disable DPPCLK RCG first. The DPPCLK_en in dccg should always be enabled when the corresponding pipe is enabled. Reviewed-by: Hansen Dsouza <hansen.dsouza(a)amd.com> Signed-off-by: Charlene Liu <Charlene.Liu(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of both the commit message and code changes, my answer is: **YES** This commit should be backported to stable kernel trees for the following reasons: ## Critical Hardware Sequencing Fix The commit addresses a fundamental hardware sequencing requirement where DPP (Display Pipes and Planes) Root Clock Gating (RCG) must be disabled before enabling the DPP clock. This is a critical timing constraint that, if violated, can cause severe system issues. ## Specific Code Evidence 1. **In `dccg35_update_dpp_dto()`**, the fix adds a crucial sequencing step: ```c + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, phase, DPPCLK0_DTO_MODULO, modulo); dcn35_set_dppclk_enable(dccg, dpp_inst, true); ``` This ensures RCG is disabled (false) before enabling the DPP clock. 2. **In `dcn35_enable_plane()`**, explicit clock control is added: ```c + /*make sure DPPCLK is on*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, true); + dpp->funcs->dpp_dppclk_control(dpp, false, true); ``` 3. **Removal of problematic init code** in `dcn35_init_hw()`: ```c - if (res_pool->dccg->funcs->dccg_root_gate_disable_control) { - for (i = 0; i < res_pool->pipe_count; i++) - res_pool->dccg->funcs->dccg_root_gate_disable_control(res_pool->dccg, i, 0); - } ``` ## Similarity to Previous Critical Fixes This commit follows the pattern of Similar Commit #1, which also addressed clock gating sequencing issues that could cause system hangs. The commit message explicitly states this is needed because "DPP CLK enable needs to disable DPPCLK RCG first." ## Impact and Risk Assessment - **Bug Fixed**: Incorrect clock sequencing that can cause system instability - **Scope**: Limited to DCN35 display hardware (recent AMD GPUs) - **Complexity**: Small, focused changes with clear purpose - **Risk**: Low risk of regression - adds proper sequencing without major architectural changes This fix meets all criteria for stable backporting: - Fixes a real bug affecting users (system stability) - Small and contained changes - No new features or architectural changes - Addresses hardware constraints that cannot be worked around The commit should be backported to all stable kernels that include DCN35 display support to ensure proper display functionality and system stability for users with affected AMD GPUs. .../amd/display/dc/dccg/dcn35/dcn35_dccg.c | 38 ++++++++++++------- .../amd/display/dc/hwss/dcn35/dcn35_hwseq.c | 21 ++++++---- 2 files changed, 38 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c b/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c index b363f5360818d..ad910065f463f 100644 --- a/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c +++ b/drivers/gpu/drm/amd/display/dc/dccg/dcn35/dcn35_dccg.c @@ -391,6 +391,7 @@ static void dccg35_set_dppclk_rcg(struct dccg *dccg, struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg); + if (!dccg->ctx->dc->debug.root_clock_optimization.bits.dpp && enable) return; @@ -411,6 +412,8 @@ static void dccg35_set_dppclk_rcg(struct dccg *dccg, BREAK_TO_DEBUGGER(); break; } + //DC_LOG_DEBUG("%s: inst(%d) DPPCLK rcg_disable: %d\n", __func__, inst, enable ? 0 : 1); + } static void dccg35_set_dpstreamclk_rcg( @@ -1112,30 +1115,24 @@ static void dcn35_set_dppclk_enable(struct dccg *dccg, { struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg); + switch (dpp_inst) { case 0: REG_UPDATE(DPPCLK_CTRL, DPPCLK0_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK0_ROOT_GATE_DISABLE, enable); break; case 1: REG_UPDATE(DPPCLK_CTRL, DPPCLK1_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK1_ROOT_GATE_DISABLE, enable); break; case 2: REG_UPDATE(DPPCLK_CTRL, DPPCLK2_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK2_ROOT_GATE_DISABLE, enable); break; case 3: REG_UPDATE(DPPCLK_CTRL, DPPCLK3_EN, enable); - if (dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) - REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK3_ROOT_GATE_DISABLE, enable); break; default: break; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) DPPCLK_EN = %d\n", __func__, dpp_inst, enable); } @@ -1163,14 +1160,18 @@ static void dccg35_update_dpp_dto(struct dccg *dccg, int dpp_inst, ASSERT(false); phase = 0xff; } + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, phase, DPPCLK0_DTO_MODULO, modulo); dcn35_set_dppclk_enable(dccg, dpp_inst, true); - } else + } else { dcn35_set_dppclk_enable(dccg, dpp_inst, false); + /*we have this in hwss: disable_plane*/ + //dccg35_set_dppclk_rcg(dccg, dpp_inst, true); + } dccg->pipe_dppclk_khz[dpp_inst] = req_dppclk; } @@ -1182,6 +1183,7 @@ static void dccg35_set_dppclk_root_clock_gating(struct dccg *dccg, if (!dccg->ctx->dc->debug.root_clock_optimization.bits.dpp) return; + switch (dpp_inst) { case 0: REG_UPDATE(DCCG_GATE_DISABLE_CNTL6, DPPCLK0_ROOT_GATE_DISABLE, enable); @@ -1198,6 +1200,8 @@ static void dccg35_set_dppclk_root_clock_gating(struct dccg *dccg, default: break; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) rcg: %d\n", __func__, dpp_inst, enable); + } static void dccg35_get_pixel_rate_div( @@ -1521,28 +1525,30 @@ static void dccg35_set_physymclk_root_clock_gating( switch (phy_inst) { case 0: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYASYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYASYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 1: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYBSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYBSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 2: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYCSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYCSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 3: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYDSYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYDSYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; case 4: REG_UPDATE(DCCG_GATE_DISABLE_CNTL2, - PHYESYMCLK_ROOT_GATE_DISABLE, enable ? 1 : 0); + PHYESYMCLK_ROOT_GATE_DISABLE, enable ? 0 : 1); break; default: BREAK_TO_DEBUGGER(); return; } + //DC_LOG_DEBUG("%s: dpp_inst(%d) PHYESYMCLK_ROOT_GATE_DISABLE:\n", __func__, phy_inst, enable ? 0 : 1); + } static void dccg35_set_physymclk( @@ -1643,6 +1649,8 @@ static void dccg35_dpp_root_clock_control( return; if (clock_on) { + dccg35_set_dppclk_rcg(dccg, dpp_inst, false); + /* turn off the DTO and leave phase/modulo at max */ dcn35_set_dppclk_enable(dccg, dpp_inst, 1); REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, @@ -1654,6 +1662,8 @@ static void dccg35_dpp_root_clock_control( REG_SET_2(DPPCLK_DTO_PARAM[dpp_inst], 0, DPPCLK0_DTO_PHASE, 0, DPPCLK0_DTO_MODULO, 1); + /*we have this in hwss: disable_plane*/ + //dccg35_set_dppclk_rcg(dccg, dpp_inst, true); } dccg->dpp_clock_gated[dpp_inst] = !clock_on; diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c index 922b8d71cf1aa..63077c1fad859 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c @@ -241,11 +241,6 @@ void dcn35_init_hw(struct dc *dc) dc->res_pool->hubbub->funcs->allow_self_refresh_control(dc->res_pool->hubbub, !dc->res_pool->hubbub->ctx->dc->debug.disable_stutter); } - if (res_pool->dccg->funcs->dccg_root_gate_disable_control) { - for (i = 0; i < res_pool->pipe_count; i++) - res_pool->dccg->funcs->dccg_root_gate_disable_control(res_pool->dccg, i, 0); - } - for (i = 0; i < res_pool->audio_count; i++) { struct audio *audio = res_pool->audios[i]; @@ -901,12 +896,18 @@ void dcn35_init_pipes(struct dc *dc, struct dc_state *context) void dcn35_enable_plane(struct dc *dc, struct pipe_ctx *pipe_ctx, struct dc_state *context) { + struct dpp *dpp = pipe_ctx->plane_res.dpp; + struct dccg *dccg = dc->res_pool->dccg; + + /* enable DCFCLK current DCHUB */ pipe_ctx->plane_res.hubp->funcs->hubp_clk_cntl(pipe_ctx->plane_res.hubp, true); /* initialize HUBP on power up */ pipe_ctx->plane_res.hubp->funcs->hubp_init(pipe_ctx->plane_res.hubp); - + /*make sure DPPCLK is on*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, true); + dpp->funcs->dpp_dppclk_control(dpp, false, true); /* make sure OPP_PIPE_CLOCK_EN = 1 */ pipe_ctx->stream_res.opp->funcs->opp_pipe_clock_control( pipe_ctx->stream_res.opp, @@ -923,6 +924,7 @@ void dcn35_enable_plane(struct dc *dc, struct pipe_ctx *pipe_ctx, // Program system aperture settings pipe_ctx->plane_res.hubp->funcs->hubp_set_vm_system_aperture_settings(pipe_ctx->plane_res.hubp, &apt); } + //DC_LOG_DEBUG("%s: dpp_inst(%d) =\n", __func__, dpp->inst); if (!pipe_ctx->top_pipe && pipe_ctx->plane_state @@ -938,6 +940,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) { struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; + struct dccg *dccg = dc->res_pool->dccg; + dc->hwss.wait_for_mpcc_disconnect(dc, dc->res_pool, pipe_ctx); @@ -955,7 +959,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) hubp->funcs->hubp_clk_cntl(hubp, false); dpp->funcs->dpp_dppclk_control(dpp, false, false); -/*to do, need to support both case*/ + dccg->funcs->dccg_root_gate_disable_control(dccg, dpp->inst, false); + hubp->power_gated = true; hubp->funcs->hubp_reset(hubp); @@ -967,6 +972,8 @@ void dcn35_plane_atomic_disable(struct dc *dc, struct pipe_ctx *pipe_ctx) pipe_ctx->top_pipe = NULL; pipe_ctx->bottom_pipe = NULL; pipe_ctx->plane_state = NULL; + //DC_LOG_DEBUG("%s: dpp_inst(%d)=\n", __func__, dpp->inst); + } void dcn35_disable_plane(struct dc *dc, struct dc_state *state, struct pipe_ctx *pipe_ctx) -- 2.39.5

1 month, 1 week

1
101
0 0

[PATCH 5.15] x86/its: Fix undefined reference to cpu_wants_rethunk_at()

by Pawan Gupta

Below error was reported in a 32-bit kernel build: static_call.c:(.ref.text+0x46): undefined reference to `cpu_wants_rethunk_at' make[1]: [Makefile:1234: vmlinux] Error This is because the definition of cpu_wants_rethunk_at() depends on CONFIG_STACK_VALIDATION which is only enabled in 64-bit mode. Define the empty function for CONFIG_STACK_VALIDATION=n, rethunk mitigation is anyways not supported without it. Reported-by: Guenter Roeck <linux(a)roeck-us.net> Fixes: 5d19a0574b75 ("x86/its: Add support for ITS-safe return thunk") Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Link: https://lore.kernel.org/stable/0f597436-5da6-4319-b918-9f57bde5634a@roeck-u… --- arch/x86/include/asm/alternative.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h index 1797f80c10de..a5f704dbb4a1 100644 --- a/arch/x86/include/asm/alternative.h +++ b/arch/x86/include/asm/alternative.h @@ -98,7 +98,7 @@ static inline u8 *its_static_thunk(int reg) } #endif -#ifdef CONFIG_RETHUNK +#if defined(CONFIG_RETHUNK) && defined(CONFIG_STACK_VALIDATION) extern bool cpu_wants_rethunk(void); extern bool cpu_wants_rethunk_at(void *addr); #else -- 2.34.1

1 month, 1 week

2
1
0 0

[merged mm-stable] mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/khugepaged: fix race with folio split/free using temporary reference has been removed from the -mm tree. Its filename was mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Shivank Garg <shivankg(a)amd.com> Subject: mm/khugepaged: fix race with folio split/free using temporary reference Date: Mon, 26 May 2025 18:28:18 +0000 hpage_collapse_scan_file() calls is_refcount_suitable(), which in turn calls folio_mapcount(). folio_mapcount() checks folio_test_large() before proceeding to folio_large_mapcount(), but there is a race window where the folio may get split/freed between these checks, triggering: VM_WARN_ON_FOLIO(!folio_test_large(folio), folio) Take a temporary reference to the folio in hpage_collapse_scan_file(). This stabilizes the folio during refcount check and prevents incorrect large folio detection due to concurrent split/free. Use helper folio_expected_ref_count() + 1 to compare with folio_ref_count() instead of using is_refcount_suitable(). Link: https://lkml.kernel.org/r/20250526182818.37978-1-shivankg@amd.com Fixes: 05c5323b2a34 ("mm: track mapcount of large folios in single value") Signed-off-by: Shivank Garg <shivankg(a)amd.com> Reported-by: syzbot+2b99589e33edbe9475ca(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6828470d.a70a0220.38f255.000c.GAE@google.com Suggested-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Dev Jain <dev.jain(a)arm.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Bharata B Rao <bharata(a)amd.com> Cc: Fengwei Yin <fengwei.yin(a)intel.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mariano Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/khugepaged.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/mm/khugepaged.c~mm-khugepaged-fix-race-with-folio-split-free-using-temporary-reference +++ a/mm/khugepaged.c @@ -2293,6 +2293,17 @@ static int hpage_collapse_scan_file(stru continue; } + if (!folio_try_get(folio)) { + xas_reset(&xas); + continue; + } + + if (unlikely(folio != xas_reload(&xas))) { + folio_put(folio); + xas_reset(&xas); + continue; + } + if (folio_order(folio) == HPAGE_PMD_ORDER && folio->index == start) { /* Maybe PMD-mapped */ @@ -2303,23 +2314,27 @@ static int hpage_collapse_scan_file(stru * it's safe to skip LRU and refcount checks before * returning. */ + folio_put(folio); break; } node = folio_nid(folio); if (hpage_collapse_scan_abort(node, cc)) { result = SCAN_SCAN_ABORT; + folio_put(folio); break; } cc->node_load[node]++; if (!folio_test_lru(folio)) { result = SCAN_PAGE_LRU; + folio_put(folio); break; } - if (!is_refcount_suitable(folio)) { + if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) { result = SCAN_PAGE_COUNT; + folio_put(folio); break; } @@ -2331,6 +2346,7 @@ static int hpage_collapse_scan_file(stru */ present += folio_nr_pages(folio); + folio_put(folio); if (need_resched()) { xas_pause(&xas); _ Patches currently in -mm which might be from shivankg(a)amd.com are

1 month, 1 week

1
0
0 0

+ kvm-s390-rename-prot_none-to-prot_type_dummy.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY has been added to the -mm mm-hotfixes-unstable branch. Its filename is kvm-s390-rename-prot_none-to-prot_type_dummy.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMY Date: Mon, 19 May 2025 15:56:57 +0100 The enum type prot_type declared in arch/s390/kvm/gaccess.c declares an unfortunate identifier within it - PROT_NONE. This clashes with the protection bit define from the uapi for mmap() declared in include/uapi/asm-generic/mman-common.h, which is indeed what those casually reading this code would assume this to refer to. This means that any changes which subsequently alter headers in any way which results in the uapi header being imported here will cause build errors. Resolve the issue by renaming PROT_NONE to PROT_TYPE_DUMMY. Link: https://lkml.kernel.org/r/20250519145657.178365-1-lorenzo.stoakes@oracle.com Fixes: b3cefd6bf16e ("KVM: s390: Pass initialized arg even if unused") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Suggested-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez(a)kuka.com> Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505140943.IgHDa9s7-lkp@intel.com/ Acked-by: Christian Borntraeger <borntraeger(a)linux.ibm.com> Acked-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez(a)kuka.com> Acked-by: Yang Shi <yang(a)os.amperecomputing.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Acked-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Reviewed-by: Claudio Imbrenda <imbrenda(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: James Houghton <jthoughton(a)google.com> Cc: Janosch Frank <frankja(a)linux.ibm.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Sven Schnelle <svens(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/s390/kvm/gaccess.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/s390/kvm/gaccess.c~kvm-s390-rename-prot_none-to-prot_type_dummy +++ a/arch/s390/kvm/gaccess.c @@ -318,7 +318,7 @@ enum prot_type { PROT_TYPE_DAT = 3, PROT_TYPE_IEP = 4, /* Dummy value for passing an initialized value when code != PGM_PROTECTION */ - PROT_NONE, + PROT_TYPE_DUMMY, }; static int trans_exc_ending(struct kvm_vcpu *vcpu, int code, unsigned long gva, u8 ar, @@ -334,7 +334,7 @@ static int trans_exc_ending(struct kvm_v switch (code) { case PGM_PROTECTION: switch (prot) { - case PROT_NONE: + case PROT_TYPE_DUMMY: /* We should never get here, acts like termination */ WARN_ON_ONCE(1); break; @@ -804,7 +804,7 @@ static int guest_range_to_gpas(struct kv gpa = kvm_s390_real_to_abs(vcpu, ga); if (!kvm_is_gpa_in_memslot(vcpu->kvm, gpa)) { rc = PGM_ADDRESSING; - prot = PROT_NONE; + prot = PROT_TYPE_DUMMY; } } if (rc) @@ -962,7 +962,7 @@ int access_guest_with_key(struct kvm_vcp if (rc == PGM_PROTECTION) prot = PROT_TYPE_KEYC; else - prot = PROT_NONE; + prot = PROT_TYPE_DUMMY; rc = trans_exc_ending(vcpu, rc, ga, ar, mode, prot, terminate); } out_unlock: _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are kvm-s390-rename-prot_none-to-prot_type_dummy.patch tools-testing-vma-add-missing-function-stub.patch

1 month, 1 week

1
0
0 0

[PATCH v2] iio: adc: adi-axi-adc: fix ad7606_bus_reg_read()

by David Lechner

Mask the value read before returning it. The value read over the parallel bus via the AXI ADC IP block contains both the address and the data, but callers expect val to only contain the data. axi_adc_raw_write() takes a u32 parameter, so addr was the wrong type. This wasn't causing any issues but is corrected anyway since we are touching the same line to add a new variable. Cc: stable(a)vger.kernel.org Fixes: 79c47485e438 ("iio: adc: adi-axi-adc: add support for AD7606 register writing") Signed-off-by: David Lechner <dlechner(a)baylibre.com> --- Changes in v2: - Use ADI_AXI_REG_VALUE_MASK instead of hard-coding 0xFF. - Introduce local variable and use FIELD_PREP() instead of modifying val. - Link to v1: https://lore.kernel.org/r/20250530-iio-adc-adi-axi-adc-fix-ad7606_bus_reg_r… --- drivers/iio/adc/adi-axi-adc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c index cf942c043457ccea49207c3900153ee371b3774f..fc745297bcb82cf2cf7f30c7fcf9bba2d861a48c 100644 --- a/drivers/iio/adc/adi-axi-adc.c +++ b/drivers/iio/adc/adi-axi-adc.c @@ -445,7 +445,7 @@ static int axi_adc_raw_read(struct iio_backend *back, u32 *val) static int ad7606_bus_reg_read(struct iio_backend *back, u32 reg, u32 *val) { struct adi_axi_adc_state *st = iio_backend_get_priv(back); - int addr; + u32 addr, reg_val; guard(mutex)(&st->lock); @@ -455,7 +455,9 @@ static int ad7606_bus_reg_read(struct iio_backend *back, u32 reg, u32 *val) */ addr = FIELD_PREP(ADI_AXI_REG_ADDRESS_MASK, reg) | ADI_AXI_REG_READ_BIT; axi_adc_raw_write(back, addr); - axi_adc_raw_read(back, val); + axi_adc_raw_read(back, &reg_val); + + *val = FIELD_GET(ADI_AXI_REG_VALUE_MASK, reg_val); /* Write 0x0 on the bus to get back to ADC mode */ axi_adc_raw_write(back, 0); --- base-commit: 7cdfbc0113d087348b8e65dd79276d0f57b89a10 change-id: 20250530-iio-adc-adi-axi-adc-fix-ad7606_bus_reg_read-f2bbb503db8b Best regards, -- David Lechner <dlechner(a)baylibre.com>

1 month, 1 week

2
1
0 0

[PATCH 1/2] apparmor: Fix 8-byte alignment for initial dfa blob streams

by deller＠kernel.org

From: Helge Deller <deller(a)gmx.de> The dfa blob stream for the aa_dfa_unpack() function is expected to be aligned on a 8 byte boundary. The static nulldfa_src[] and stacksplitdfa_src[] arrays store the inital apparmor dfa blob streams, but since they are declared as an array-of-chars the compiler and linker will only ensure a "char" (1-byte) alignment. Add an __aligned(8) annotation to the arrays to tell the linker to always align them on a 8-byte boundary. This avoids runtime warnings at startup on alignment-sensitive platforms like parisc such as: Kernel: unaligned access to 0x7f2a584a in aa_dfa_unpack+0x124/0x788 (iir 0xca0109f) Kernel: unaligned access to 0x7f2a584e in aa_dfa_unpack+0x210/0x788 (iir 0xca8109c) Kernel: unaligned access to 0x7f2a586a in aa_dfa_unpack+0x278/0x788 (iir 0xcb01090) Signed-off-by: Helge Deller <deller(a)gmx.de> Cc: stable(a)vger.kernel.org --- security/apparmor/lsm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c index 9b6c2f157f83..531bde29cccb 100644 --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -2149,12 +2149,12 @@ static int __init apparmor_nf_ip_init(void) __initcall(apparmor_nf_ip_init); #endif -static char nulldfa_src[] = { +static char nulldfa_src[] __aligned(8) = { #include "nulldfa.in" }; static struct aa_dfa *nulldfa; -static char stacksplitdfa_src[] = { +static char stacksplitdfa_src[] __aligned(8) = { #include "stacksplitdfa.in" }; struct aa_dfa *stacksplitdfa; -- 2.47.0

1 month, 1 week

1
0
0 0

Re: 6.1.140 build failure(fs/btrfs/discard.c:247:5: error: implicit declaration of function 'ASSERT')

by Filipe Manana

On Mon, May 26, 2025 at 6:40 AM Wang Yugui <wangyugui(a)e16-tech.com> wrote: > > Hi, > Cc: Filipe Manana > > I noticed 6.1.140 build failure(fs/btrfs/discard.c:247:5: error: implicit declaration of function 'ASSERT') > > fs/btrfs/discard.c: In function 'peek_discard_list': > fs/btrfs/discard.c:247:5: error: implicit declaration of function 'ASSERT'; did you mean 'IS_ERR'? [-Werror=implicit-function-declaration] > ASSERT(block_group->discard_index != > ^~~~~~ > IS_ERR > > It seems realted to the patch(btrfs-fix-discard-worker-infinite-loop-after-disabling-discard.patch). Yes, it is. The patch, like most stable backports, was automatically picked by the stable scripts and added to stable releases. I assume that before the release was made, it was compile tested by the stable automatic processes. I just tried it, and it compiles successfully for me: fdmanana 11:56:26 ~/git/hub/linux ((v6.12))> git clean -xfd fdmanana 11:57:27 ~/git/hub/linux ((v6.12))> git co v6.1.140 fdmanana 11:59:53 ~/git/hub/linux ((v6.1.140))> make defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/menu.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # # Run make menuconfig to enable btrfs and all its config options fdmanana 12:01:55 ~/git/hub/linux ((v6.1.140))> make menuconfig fdmanana 12:02:17 ~/git/hub/linux ((v6.1.140))> grep BTRFS .config CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_BTRFS_FS_CHECK_INTEGRITY=y CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y CONFIG_BTRFS_DEBUG=y CONFIG_BTRFS_ASSERT=y CONFIG_BTRFS_FS_REF_VERIFY=y fdmanana 12:06:08 ~/git/hub/linux ((v6.1.140))> make fs/btrfs/btrfs.ko SYNC include/config/auto.conf CALL scripts/checksyscalls.sh DESCEND objtool CC [M] fs/btrfs/super.o CC [M] fs/btrfs/ctree.o CC [M] fs/btrfs/extent-tree.o CC [M] fs/btrfs/print-tree.o CC [M] fs/btrfs/root-tree.o CC [M] fs/btrfs/dir-item.o CC [M] fs/btrfs/file-item.o CC [M] fs/btrfs/inode-item.o CC [M] fs/btrfs/disk-io.o CC [M] fs/btrfs/transaction.o CC [M] fs/btrfs/inode.o CC [M] fs/btrfs/file.o CC [M] fs/btrfs/tree-defrag.o CC [M] fs/btrfs/extent_map.o CC [M] fs/btrfs/sysfs.o CC [M] fs/btrfs/struct-funcs.o CC [M] fs/btrfs/xattr.o CC [M] fs/btrfs/ordered-data.o CC [M] fs/btrfs/extent_io.o CC [M] fs/btrfs/volumes.o CC [M] fs/btrfs/async-thread.o CC [M] fs/btrfs/ioctl.o CC [M] fs/btrfs/locking.o CC [M] fs/btrfs/orphan.o CC [M] fs/btrfs/export.o CC [M] fs/btrfs/tree-log.o CC [M] fs/btrfs/free-space-cache.o CC [M] fs/btrfs/lzo.o CC [M] fs/btrfs/zstd.o CC [M] fs/btrfs/compression.o CC [M] fs/btrfs/delayed-ref.o CC [M] fs/btrfs/relocation.o CC [M] fs/btrfs/delayed-inode.o CC [M] fs/btrfs/scrub.o CC [M] fs/btrfs/backref.o CC [M] fs/btrfs/ulist.o CC [M] fs/btrfs/qgroup.o CC [M] fs/btrfs/send.o CC [M] fs/btrfs/dev-replace.o CC [M] fs/btrfs/raid56.o CC [M] fs/btrfs/uuid-tree.o CC [M] fs/btrfs/props.o CC [M] fs/btrfs/free-space-tree.o CC [M] fs/btrfs/tree-checker.o CC [M] fs/btrfs/space-info.o CC [M] fs/btrfs/block-rsv.o CC [M] fs/btrfs/delalloc-space.o CC [M] fs/btrfs/block-group.o CC [M] fs/btrfs/discard.o CC [M] fs/btrfs/reflink.o CC [M] fs/btrfs/subpage.o CC [M] fs/btrfs/tree-mod-log.o CC [M] fs/btrfs/extent-io-tree.o CC [M] fs/btrfs/acl.o CC [M] fs/btrfs/check-integrity.o CC [M] fs/btrfs/ref-verify.o CC [M] fs/btrfs/tests/free-space-tests.o CC [M] fs/btrfs/tests/extent-buffer-tests.o CC [M] fs/btrfs/tests/btrfs-tests.o CC [M] fs/btrfs/tests/extent-io-tests.o CC [M] fs/btrfs/tests/inode-tests.o CC [M] fs/btrfs/tests/qgroup-tests.o CC [M] fs/btrfs/tests/free-space-tree-tests.o CC [M] fs/btrfs/tests/extent-map-tests.o LD [M] fs/btrfs/btrfs.o make[3]: 'fs/btrfs/btrfs.mod' is up to date. MODPOST modules-only.symvers WARNING: vmlinux.o is missing. Modules may not have dependencies or modversions. You may get many unresolved symbol warnings. WARNING: modpost: "bio_associate_blkg" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "zstd_cstream_workspace_bound" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "folio_invalidate" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "__page_file_index" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "strcpy" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "inode_init_owner" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "generic_fillattr" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "is_vmalloc_addr" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "krealloc" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: "vfs_fsync_range" [fs/btrfs/btrfs.ko] undefined! WARNING: modpost: suppressed 521 unresolved symbol warnings because there were too many) LD [M] fs/btrfs/btrfs.ko fdmanana 12:11:12 ~/git/hub/linux ((v6.1.140))> gcc --version gcc (Debian 9.3.0-18) 9.3.0 > > I walked around it with the following patch. In the future please cc the stable list when you find problems with stable backports. > > diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c > index 98bce18..9ffe5c4 100644 > --- a/fs/btrfs/discard.c > +++ b/fs/btrfs/discard.c > @@ -7,6 +7,7 @@ > #include <linux/math64.h> > #include <linux/sizes.h> > #include <linux/workqueue.h> > +#include "messages.h" > #include "ctree.h" > #include "block-group.h" > #include "discard.h" > > > Best Regards > Wang Yugui (wangyugui(a)e16-tech.com) > 2025/05/26 > > >

1 month, 1 week

2
1
0 0

ISE 2025 Visitors Contacts-20% OFF!

by Garnet Conwell

Hi, We’re excited to share exclusive access to the Integrated Systems Europe 2025 Visitor Contact List! Our database includes 88,351 verified visitor contacts, giving you a powerful resource to connect with key industry professionals. Each contact includes: Contact Name, Job Title, Company Name, Physical Address, Phone Number, Official Email Address, and more. Interested in the list? Simply reply with “Send me Pricing” to get full details. Kind regards, Garnet Conwell Sr. Marketing Manager To opt out of future messages, just reply “Unfollow.”

1 month, 1 week

1
0
0 0

[PATCH] mm: userfaultfd: fix race of userfaultfd_move and swap cache

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache lookup, and try to move the found folio to the faulting vma when. Currently, it relies on the PTE value check to ensure the moved folio still belongs to the src swap entry, which turns out is not reliable. While working and reviewing the swap table series with Barry, following existing race is observed and reproduced [1]: ( move_pages_pte is moving src_pte to dst_pte, where src_pte is a swap entry PTE holding swap entry S1, and S1 isn't in the swap cache.) CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... < Somehow interrupted> ... <swapin src_pte, alloc and use folio A> // folio A is just a new allocated folio // and get installed into src_pte <frees swap entry S1> // src_pte now points to folio A, S1 // has swap count == 0, it can be freed // by folio_swap_swap or swap // allocator's reclaim. <try to swap out another folio B> // folio B is a folio in another VMA. <put folio B to swap cache using S1 > // S1 is freed, folio B could use it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... < Somehow interrupted again> ... <swapin folio B and free S1> // Now S1 is free to be used again. <swapout src_pte & folio A using S1> // Now src_pte is a swap entry pte // holding S1 again. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // Moved invalid folio B here !!! The race window is very short and requires multiple collisions of multiple rare events, so it's very unlikely to happen, but with a deliberately constructed reproducer and increased time window, it can be reproduced [1]. It's also possible that folio (A) is swapped in, and swapped out again after the filemap_get_folio lookup, in such case folio (A) may stay in swap cache so it needs to be moved too. In this case we should also try again so kernel won't miss a folio move. Fix this by checking if the folio is the valid swap cache folio after acquiring the folio lock, and checking the swap cache again after acquiring the src_pte lock. SWP_SYNCRHONIZE_IO path does make the problem more complex, but so far we don't need to worry about that since folios only might get exposed to swap cache in the swap out path, and it's covered in this patch too by checking the swap cache again after acquiring src_pte lock. Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Closes: https://lore.kernel.org/linux-mm/CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoS… [1] Signed-off-by: Kairui Song <kasong(a)tencent.com> --- mm/userfaultfd.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index bc473ad21202..a1564d205dfb 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -15,6 +15,7 @@ #include <linux/mmu_notifier.h> #include <linux/hugetlb.h> #include <linux/shmem_fs.h> +#include <linux/delay.h> #include <asm/tlbflush.h> #include <asm/tlb.h> #include "internal.h" @@ -1086,6 +1087,8 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, spinlock_t *dst_ptl, spinlock_t *src_ptl, struct folio *src_folio) { + swp_entry_t entry; + double_pt_lock(dst_ptl, src_ptl); if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig_src_pte, @@ -1102,6 +1105,19 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, if (src_folio) { folio_move_anon_rmap(src_folio, dst_vma); src_folio->index = linear_page_index(dst_vma, dst_addr); + } else { + /* + * Check again after acquiring the src_pte lock. Or we might + * miss a new loaded swap cache folio. + */ + entry = pte_to_swp_entry(orig_src_pte); + src_folio = filemap_get_folio(swap_address_space(entry), + swap_cache_index(entry)); + if (!IS_ERR_OR_NULL(src_folio)) { + double_pt_unlock(dst_ptl, src_ptl); + folio_put(src_folio); + return -EAGAIN; + } } orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte); @@ -1409,6 +1425,16 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, folio_lock(src_folio); goto retry; } + /* + * Check if the folio still belongs to the target swap entry after + * acquiring the lock. Folio can be freed in the swap cache while + * not locked. + */ + if (unlikely(!folio_test_swapcache(folio) || + entry.val != folio->swap.val)) { + err = -EAGAIN; + goto out; + } } err = move_swap_pte(mm, dst_vma, dst_addr, src_addr, dst_pte, src_pte, orig_dst_pte, orig_src_pte, dst_pmd, dst_pmdval, -- 2.49.0

1 month, 1 week

4
16
0 0

[PATCH net,v3] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp()

by Saurabh Sengar

The MANA driver's probe registers netdevice via the following call chain: mana_probe() register_netdev() register_netdevice() register_netdevice() calls notifier callback for netvsc driver, holding the netdev mutex via netdev_lock_ops(). Further this netvsc notifier callback end up attempting to acquire the same lock again in dev_xdp_propagate() leading to deadlock. netvsc_netdev_event() netvsc_vf_setxdp() dev_xdp_propagate() This deadlock was not observed so far because net_shaper_ops was never set, and thus the lock was effectively a no-op in this case. Fix this by using netif_xdp_propagate() instead of dev_xdp_propagate() to avoid recursive locking in this path. And, since no deadlock is observed on the other path which is via netvsc_probe, add the lock exclusivly for that path. Also, clean up the unregistration path by removing the unnecessary call to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already performs this cleanup via dev_xdp_uninstall(). Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf") Cc: stable(a)vger.kernel.org Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> Tested-by: Erni Sri Satya Vennela <ernis(a)linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Subbaraya Sundeep <sbhatta(a)marvell.com> --- [V3] - Add the lock for netvsc probe path [V2] - Modified commit message drivers/net/hyperv/netvsc_bpf.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 4 ++-- net/core/dev.c | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c index e01c5997a551..1dd3755d9e6d 100644 --- a/drivers/net/hyperv/netvsc_bpf.c +++ b/drivers/net/hyperv/netvsc_bpf.c @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog) xdp.command = XDP_SETUP_PROG; xdp.prog = prog; - ret = dev_xdp_propagate(vf_netdev, &xdp); + ret = netif_xdp_propagate(vf_netdev, &xdp); if (ret && prog) bpf_prog_put(prog); diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 14a0d04e21ae..c41a025c66f0 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2462,8 +2462,6 @@ static int netvsc_unregister_vf(struct net_device *vf_netdev) netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name); - netvsc_vf_setxdp(vf_netdev, NULL); - reinit_completion(&net_device_ctx->vf_add); netdev_rx_handler_unregister(vf_netdev); netdev_upper_dev_unlink(vf_netdev, ndev); @@ -2631,7 +2629,9 @@ static int netvsc_probe(struct hv_device *dev, continue; netvsc_prepare_bonding(vf_netdev); + netdev_lock_ops(vf_netdev); netvsc_register_vf(vf_netdev, VF_REG_IN_PROBE); + netdev_unlock_ops(vf_netdev); __netvsc_vf_setup(net, vf_netdev); break; } diff --git a/net/core/dev.c b/net/core/dev.c index 2b514d95c528..a388f459a366 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9968,6 +9968,7 @@ int netif_xdp_propagate(struct net_device *dev, struct netdev_bpf *bpf) return dev->netdev_ops->ndo_bpf(dev, bpf); } +EXPORT_SYMBOL_GPL(netif_xdp_propagate); u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode) { -- 2.43.0

1 month, 1 week

2
1
0 0

[PATCH] iio: adc: adi-axi-adc: fix ad7606_bus_reg_read()

by David Lechner

Mask the value read before returning it. The value read over the parallel bus via the AXI ADC IP block contains both the address and the data, but callers expect val to only contain the data. Cc: stable(a)vger.kernel.org Fixes: 79c47485e438 ("iio: adc: adi-axi-adc: add support for AD7606 register writing") Signed-off-by: David Lechner <dlechner(a)baylibre.com> --- drivers/iio/adc/adi-axi-adc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c index cf942c043457ccea49207c3900153ee371b3774f..d4759a98b4062bc25ea088e3868806e82db03e8d 100644 --- a/drivers/iio/adc/adi-axi-adc.c +++ b/drivers/iio/adc/adi-axi-adc.c @@ -457,6 +457,9 @@ static int ad7606_bus_reg_read(struct iio_backend *back, u32 reg, u32 *val) axi_adc_raw_write(back, addr); axi_adc_raw_read(back, val); + /* Register value is 8 bits. Remove address bits. */ + *val &= 0xFF; + /* Write 0x0 on the bus to get back to ADC mode */ axi_adc_raw_write(back, 0); --- base-commit: 7cdfbc0113d087348b8e65dd79276d0f57b89a10 change-id: 20250530-iio-adc-adi-axi-adc-fix-ad7606_bus_reg_read-f2bbb503db8b Best regards, -- David Lechner <dlechner(a)baylibre.com>

1 month, 1 week

1
2
0 0

[PATCH resend 2/2] jffs2: initialize inocache earlier

by Fedor Pchelkin

Inside jffs2_new_inode() there is a small gap when jffs2_init_acl_pre() or jffs2_do_new_inode() may fail e.g. due to a memory allocation error while uninit inocache field is touched upon subsequent inode eviction. general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 0 PID: 10592 Comm: syz-executor.1 Not tainted 5.10.209-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_xattr_delete_inode+0x35/0x130 fs/jffs2/xattr.c:602 Call Trace: jffs2_do_clear_inode+0x4c/0x570 fs/jffs2/readinode.c:1418 evict+0x281/0x6b0 fs/inode.c:577 iput_final fs/inode.c:1697 [inline] iput.part.0+0x4df/0x6d0 fs/inode.c:1723 iput+0x58/0x80 fs/inode.c:1713 jffs2_new_inode+0xb12/0xdb0 fs/jffs2/fs.c:469 jffs2_create+0x90/0x400 fs/jffs2/dir.c:177 lookup_open.isra.0+0xead/0x1260 fs/namei.c:3169 open_last_lookups fs/namei.c:3239 [inline] path_openat+0x96c/0x2670 fs/namei.c:3428 do_filp_open+0x1a4/0x3f0 fs/namei.c:3458 do_sys_openat2+0x171/0x420 fs/open.c:1186 do_sys_open fs/open.c:1202 [inline] __do_sys_openat fs/open.c:1218 [inline] __se_sys_openat fs/open.c:1213 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1213 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 Initialize the inocache pointer to a NULL value while preparing an inode in jffs2_init_inode_info(). jffs2_xattr_delete_inode() will handle it later just fine. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/jffs2/os-linux.h | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jffs2/os-linux.h b/fs/jffs2/os-linux.h index 86ab014a349c..39b6565f10c9 100644 --- a/fs/jffs2/os-linux.h +++ b/fs/jffs2/os-linux.h @@ -55,6 +55,7 @@ static inline void jffs2_init_inode_info(struct jffs2_inode_info *f) f->metadata = NULL; f->dents = NULL; f->target = NULL; + f->inocache = NULL; f->flags = 0; f->usercompr = 0; } -- 2.49.0

1 month, 1 week

1
0
0 0

[PATCH resend 1/2] jffs2: initialize filesystem-private inode info in ->alloc_inode callback

by Fedor Pchelkin

The symlink body (->target) should be freed at the same time as the inode itself per commit 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal"). It is a filesystem-specific field but there exist several error paths during generic inode allocation when ->free_inode(), namely jffs2_free_inode(), is called with still uninitialized private info. The calltrace looks like: alloc_inode inode_init_always // fails i_callback free_inode jffs2_free_inode // touches uninit ->target field Commit af9a8730ddb6 ("jffs2: Fix potential illegal address access in jffs2_free_inode") approached the observed problem but fixed it only partially. Our local Syzkaller instance is still hitting these kinds of failures. The thing is that jffs2_i_init_once(), where the initialization of f->target has been moved, is called once per slab allocation so it won't be called for the object structure possibly retrieved later from the slab cache for reuse. The practice followed by many other filesystems is to initialize filesystem-private inode contents in the corresponding ->alloc_inode() callbacks. This also allows to drop initialization from jffs2_iget() and jffs2_new_inode() as ->alloc_inode() is called in those places. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/jffs2/fs.c | 2 -- fs/jffs2/super.c | 3 ++- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index d175cccb7c55..85c4b273918f 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -271,7 +271,6 @@ struct inode *jffs2_iget(struct super_block *sb, unsigned long ino) f = JFFS2_INODE_INFO(inode); c = JFFS2_SB_INFO(inode->i_sb); - jffs2_init_inode_info(f); mutex_lock(&f->sem); ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node); @@ -439,7 +438,6 @@ struct inode *jffs2_new_inode (struct inode *dir_i, umode_t mode, struct jffs2_r return ERR_PTR(-ENOMEM); f = JFFS2_INODE_INFO(inode); - jffs2_init_inode_info(f); mutex_lock(&f->sem); memset(ri, 0, sizeof(*ri)); diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 4545f885c41e..b56ff63357f3 100644 --- a/fs/jffs2/super.c +++ b/fs/jffs2/super.c @@ -42,6 +42,8 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb) f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL); if (!f) return NULL; + + jffs2_init_inode_info(f); return &f->vfs_inode; } @@ -58,7 +60,6 @@ static void jffs2_i_init_once(void *foo) struct jffs2_inode_info *f = foo; mutex_init(&f->sem); - f->target = NULL; inode_init_once(&f->vfs_inode); } -- 2.49.0

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/mm/init: Handle the special case of device private pages" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 7170130e4c72ce0caa0cb42a1627c635cc262821 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052750-fondness-revocable-a23b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7170130e4c72ce0caa0cb42a1627c635cc262821 Mon Sep 17 00:00:00 2001 From: Balbir Singh <balbirs(a)nvidia.com> Date: Tue, 1 Apr 2025 11:07:52 +1100 Subject: [PATCH] x86/mm/init: Handle the special case of device private pages in add_pages(), to not increase max_pfn and trigger dma_addressing_limited() bounce buffers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As Bert Karwatzki reported, the following recent commit causes a performance regression on AMD iGPU and dGPU systems: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") It exposed a bug with nokaslr and zone device interaction. The root cause of the bug is that, the GPU driver registers a zone device private memory region. When KASLR is disabled or the above commit is applied, the direct_map_physmem_end is set to much higher than 10 TiB typically to the 64TiB address. When zone device private memory is added to the system via add_pages(), it bumps up the max_pfn to the same value. This causes dma_addressing_limited() to return true, since the device cannot address memory all the way up to max_pfn. This caused a regression for games played on the iGPU, as it resulted in the DMA32 zone being used for GPU allocations. Fix this by not bumping up max_pfn on x86 systems, when pgmap is passed into add_pages(). The presence of pgmap is used to determine if device private memory is being added via add_pages(). More details: devm_request_mem_region() and request_free_mem_region() request for device private memory. iomem_resource is passed as the base resource with start and end parameters. iomem_resource's end depends on several factors, including the platform and virtualization. On x86 for example on bare metal, this value is set to boot_cpu_data.x86_phys_bits. boot_cpu_data.x86_phys_bits can change depending on support for MKTME. By default it is set to the same as log2(direct_map_physmem_end) which is 46 to 52 bits depending on the number of levels in the page table. The allocation routines used iomem_resource's end and direct_map_physmem_end to figure out where to allocate the region. [ arch/powerpc is also impacted by this problem, but this patch does not fix the issue for PowerPC. ] Testing: 1. Tested on a virtual machine with test_hmm for zone device inseration 2. A previous version of this patch was tested by Bert, please see: https://lore.kernel.org/lkml/d87680bab997fdc9fb4e638983132af235d9a03a.camel… [ mingo: Clarified the comments and the changelog. ] Reported-by: Bert Karwatzki <spasswolf(a)web.de> Tested-by: Bert Karwatzki <spasswolf(a)web.de> Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") Signed-off-by: Balbir Singh <balbirs(a)nvidia.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Juergen Gross <jgross(a)suse.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Link: https://lore.kernel.org/r/20250401000752.249348-1-balbirs@nvidia.com diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 519aa53114fa..821a0b53b21c 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -959,9 +959,18 @@ int add_pages(int nid, unsigned long start_pfn, unsigned long nr_pages, ret = __add_pages(nid, start_pfn, nr_pages, params); WARN_ON_ONCE(ret); - /* update max_pfn, max_low_pfn and high_memory */ - update_end_of_memory_vars(start_pfn << PAGE_SHIFT, - nr_pages << PAGE_SHIFT); + /* + * Special case: add_pages() is called by memremap_pages() for adding device + * private pages. Do not bump up max_pfn in the device private path, + * because max_pfn changes affect dma_addressing_limited(). + * + * dma_addressing_limited() returning true when max_pfn is the device's + * addressable memory can force device drivers to use bounce buffers + * and impact their performance negatively: + */ + if (!params->pgmap) + /* update max_pfn, max_low_pfn and high_memory */ + update_end_of_memory_vars(start_pfn << PAGE_SHIFT, nr_pages << PAGE_SHIFT); return ret; }

1 month, 1 week

4
5
0 0

[PATCH 3/3] ASoC: amd: acp3x-pdm-dma: free pdm device data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp_pdm_dma_open() and needs to be freed in the corresponding ->close() callback. Found by Linux Verification Center (linuxtesting.org). Fixes: 4a767b1d039a ("ASoC: amd: add acp3x pdm driver dma ops") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/renoir/acp3x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/amd/renoir/acp3x-pdm-dma.c b/sound/soc/amd/renoir/acp3x-pdm-dma.c index 95ac8c680037..6b294040e164 100644 --- a/sound/soc/amd/renoir/acp3x-pdm-dma.c +++ b/sound/soc/amd/renoir/acp3x-pdm-dma.c @@ -301,9 +301,11 @@ static int acp_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) { struct pdm_dev_data *adata = dev_get_drvdata(component->dev); + struct snd_pcm_runtime *runtime = substream->runtime; disable_pdm_interrupts(adata->acp_base); adata->capture_stream = NULL; + kfree(runtime->private_data); return 0; } -- 2.49.0

1 month, 1 week

1
0
0 0

[PATCH 2/3] ASoC: amd: acp3x-pcm-dma: free runtime private data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp3x_dma_open() and needs to be freed in the corresponding ->close() callback. Found by Linux Verification Center (linuxtesting.org). Fixes: c9fe7db6e884 ("ASoC: amd: Refactoring of DAI from DMA driver") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/raven/acp3x-pcm-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c b/sound/soc/amd/raven/acp3x-pcm-dma.c index bb9ed52d744d..90559c8304bc 100644 --- a/sound/soc/amd/raven/acp3x-pcm-dma.c +++ b/sound/soc/amd/raven/acp3x-pcm-dma.c @@ -353,7 +353,7 @@ static int acp3x_dma_close(struct snd_soc_component *component, adata->i2ssp_capture_stream = NULL; } } - + kfree(ins); return 0; } -- 2.49.0

1 month, 1 week

1
0
0 0

[PATCH 1/3] ASoC: amd: acp6x-pdm-dma: free pdm device data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp6x_pdm_dma_open() and needs to be freed in the corresponding ->close() callback. unreferenced object 0xffff88813525a940 (size 32): comm "pipewire", pid 1238, jiffies 4294728195 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 3c 03 00 c9 ff ff ..........<..... backtrace (crc 14400236): __kmalloc_cache_noprof+0x3a3/0x490 acp6x_pdm_dma_open+0x10d/0x680 [snd_acp6x_pdm_dma] snd_soc_component_open+0x71/0x150 [snd_soc_core] __soc_pcm_open+0x221/0xb40 [snd_soc_core] soc_pcm_open+0x99/0x110 [snd_soc_core] snd_pcm_open_substream+0x18b/0x4e0 [snd_pcm] snd_pcm_open+0x244/0x670 [snd_pcm] snd_pcm_capture_open+0x72/0xd0 [snd_pcm] chrdev_open+0x1eb/0x5e0 do_dentry_open+0x494/0x1820 vfs_open+0x7a/0x440 do_open+0x3d0/0xd30 path_openat+0x1d3/0x580 do_filp_open+0x1c5/0x450 do_sys_openat2+0xef/0x180 __x64_sys_openat+0x10e/0x210 Found by Linux Verification Center (linuxtesting.org). Fixes: ceb4fcc13ae5 ("ASoC: amd: add acp6x pdm driver dma ops") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/yc/acp6x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-pdm-dma.c b/sound/soc/amd/yc/acp6x-pdm-dma.c index ac758b90f441..167cd792d33d 100644 --- a/sound/soc/amd/yc/acp6x-pdm-dma.c +++ b/sound/soc/amd/yc/acp6x-pdm-dma.c @@ -275,9 +275,11 @@ static int acp6x_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) { struct pdm_dev_data *adata = dev_get_drvdata(component->dev); + struct snd_pcm_runtime *runtime = substream->runtime; acp6x_disable_pdm_interrupts(adata->acp6x_base); adata->capture_stream = NULL; + kfree(runtime->private_data); return 0; } -- 2.49.0

1 month, 1 week

1
0
0 0

[PATCH AUTOSEL 5.4 1/6] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

1 month, 1 week

1
5
0 0

[PATCH AUTOSEL 5.10 01/10] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

1 month, 1 week

1
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror