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

5.10 kernel series fails to build on newer toolchain: FAILED unresolved symbol filp_close

by Philip Müller

For some odd reason 5.10 kernel series doesn't compile with a newer toolchain since 2025-02-09: 2025-02-09T17:32:07.7991299Z GEN .version 2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h 2025-02-09T17:32:07.8540777Z LD vmlinux.o 2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers 2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo 2025-02-09T17:32:12.1403022Z GEN modules.builtin 2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf 2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o 2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1 2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S 2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o 2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2 2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S 2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o 2025-02-09T17:32:40.3659440Z LD vmlinux 2025-02-09T17:32:48.0031558Z BTFIDS vmlinux 2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close 2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255 2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build(). 5.10.234 built fine couple of days ago with the older one. There were slight changes made. 5.4 and 5.15 still compile. Wonder what might be missing here ... -- Best, Philip

2 months, 3 weeks

4
13
0 0

[PATCH AUTOSEL 5.4 1/7] ALSA: sb: Force to disable DMAs once when DMA mode is changed

by Sasha Levin

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit 4c267ae2ef349639b4d9ebf00dd28586a82fdbe6 ] When the DMA mode is changed on the (still real!) SB AWE32 after playing a stream and closing, the previous DMA setup was still silently kept, and it can confuse the hardware, resulting in the unexpected noises. As a workaround, enforce the disablement of DMA setups when the DMA setup is changed by the kcontrol. https://bugzilla.kernel.org/show_bug.cgi?id=218185 Link: https://patch.msgid.link/20250610064322.26787-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of the commit message and code changes, here is my assessment: **YES** - This commit should be backported to stable kernel trees. ## Extensive Explanation: ### 1. **Bug Fix Nature** This commit fixes a real bug that causes "unexpected noises" on SB AWE32 hardware when DMA mode is changed after playing a stream. The fix addresses a situation where "the previous DMA setup was still silently kept, and it can confuse the hardware." ### 2. **Code Change Analysis** The fix is minimal and surgical: ```c if (change) { snd_dma_disable(chip->dma8); snd_dma_disable(chip->dma16); } ``` This adds only 4 lines that disable both DMA channels when the DMA mode control changes. The fix is: - **Small and contained**: Only affects the `snd_sb16_dma_control_put()` function - **Low risk**: Simply ensures DMA channels are disabled during mode switches - **Clear purpose**: Prevents hardware confusion from stale DMA configurations ### 3. **Hardware Bug Context** The kernel repository analysis reveals this is addressing a known class of hardware issues with SB16 cards: - The driver documents hardware bugs with DMA mode switching (lines 14-18 in sb16_main.c) - The hardware has separate 8-bit and 16-bit DMA channels that cannot mix - Certain chip revisions have bugs where DMA transfers can block when switching modes ### 4. **Safety and Side Effects** The change has minimal side effects: - Only executes when user changes the DMA mode control - The driver already checks for active playback/capture before allowing changes (`if (chip->mode & (SB_MODE_PLAYBACK | SB_MODE_CAPTURE)) return -EBUSY;`) - `snd_dma_disable()` is a standard ISA DMA function that safely disables DMA transfers - The prepare functions already disable/enable DMAs during normal operation ### 5. **Stable Tree Criteria** This meets stable tree criteria: - **Fixes a real bug**: Users experience actual audio problems (unexpected noises) - **No new features**: Pure bug fix, no feature additions - **Minimal change**: 4 lines of straightforward code - **Low regression risk**: Only affects legacy ISA hardware (SB16/AWE32) - **Clear bug report**: References kernel bugzilla #218185 ### 6. **Legacy Hardware Consideration** While SB16 is legacy hardware, it's still used: - The bug report is recent (bugzilla #218185) - The commit message states this affects "still real!" hardware - Linux maintains support for legacy hardware in stable trees - The fix prevents audio corruption which significantly impacts user experience The commit follows the pattern of similar audio driver fixes that were backported (like commit #1 in the examples which fixed DMA synchronization issues). It's a targeted fix for a specific hardware problem with no architectural changes. sound/isa/sb/sb16_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c index 679f9f48370ff..b69bc83c103c3 100644 --- a/sound/isa/sb/sb16_main.c +++ b/sound/isa/sb/sb16_main.c @@ -722,6 +722,10 @@ static int snd_sb16_dma_control_put(struct snd_kcontrol *kcontrol, struct snd_ct change = nval != oval; snd_sb16_set_dma_mode(chip, nval); spin_unlock_irqrestore(&chip->reg_lock, flags); + if (change) { + snd_dma_disable(chip->dma8); + snd_dma_disable(chip->dma16); + } return change; } -- 2.39.5

2 months, 3 weeks

1
6
0 0

[PATCH AUTOSEL 5.10 1/8] ALSA: sb: Force to disable DMAs once when DMA mode is changed

by Sasha Levin

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit 4c267ae2ef349639b4d9ebf00dd28586a82fdbe6 ] When the DMA mode is changed on the (still real!) SB AWE32 after playing a stream and closing, the previous DMA setup was still silently kept, and it can confuse the hardware, resulting in the unexpected noises. As a workaround, enforce the disablement of DMA setups when the DMA setup is changed by the kcontrol. https://bugzilla.kernel.org/show_bug.cgi?id=218185 Link: https://patch.msgid.link/20250610064322.26787-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of the commit message and code changes, here is my assessment: **YES** - This commit should be backported to stable kernel trees. ## Extensive Explanation: ### 1. **Bug Fix Nature** This commit fixes a real bug that causes "unexpected noises" on SB AWE32 hardware when DMA mode is changed after playing a stream. The fix addresses a situation where "the previous DMA setup was still silently kept, and it can confuse the hardware." ### 2. **Code Change Analysis** The fix is minimal and surgical: ```c if (change) { snd_dma_disable(chip->dma8); snd_dma_disable(chip->dma16); } ``` This adds only 4 lines that disable both DMA channels when the DMA mode control changes. The fix is: - **Small and contained**: Only affects the `snd_sb16_dma_control_put()` function - **Low risk**: Simply ensures DMA channels are disabled during mode switches - **Clear purpose**: Prevents hardware confusion from stale DMA configurations ### 3. **Hardware Bug Context** The kernel repository analysis reveals this is addressing a known class of hardware issues with SB16 cards: - The driver documents hardware bugs with DMA mode switching (lines 14-18 in sb16_main.c) - The hardware has separate 8-bit and 16-bit DMA channels that cannot mix - Certain chip revisions have bugs where DMA transfers can block when switching modes ### 4. **Safety and Side Effects** The change has minimal side effects: - Only executes when user changes the DMA mode control - The driver already checks for active playback/capture before allowing changes (`if (chip->mode & (SB_MODE_PLAYBACK | SB_MODE_CAPTURE)) return -EBUSY;`) - `snd_dma_disable()` is a standard ISA DMA function that safely disables DMA transfers - The prepare functions already disable/enable DMAs during normal operation ### 5. **Stable Tree Criteria** This meets stable tree criteria: - **Fixes a real bug**: Users experience actual audio problems (unexpected noises) - **No new features**: Pure bug fix, no feature additions - **Minimal change**: 4 lines of straightforward code - **Low regression risk**: Only affects legacy ISA hardware (SB16/AWE32) - **Clear bug report**: References kernel bugzilla #218185 ### 6. **Legacy Hardware Consideration** While SB16 is legacy hardware, it's still used: - The bug report is recent (bugzilla #218185) - The commit message states this affects "still real!" hardware - Linux maintains support for legacy hardware in stable trees - The fix prevents audio corruption which significantly impacts user experience The commit follows the pattern of similar audio driver fixes that were backported (like commit #1 in the examples which fixed DMA synchronization issues). It's a targeted fix for a specific hardware problem with no architectural changes. sound/isa/sb/sb16_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c index aa48705310231..19804d3fd98c4 100644 --- a/sound/isa/sb/sb16_main.c +++ b/sound/isa/sb/sb16_main.c @@ -710,6 +710,10 @@ static int snd_sb16_dma_control_put(struct snd_kcontrol *kcontrol, struct snd_ct change = nval != oval; snd_sb16_set_dma_mode(chip, nval); spin_unlock_irqrestore(&chip->reg_lock, flags); + if (change) { + snd_dma_disable(chip->dma8); + snd_dma_disable(chip->dma16); + } return change; } -- 2.39.5

2 months, 3 weeks

1
7
0 0

[PATCH AUTOSEL 5.15 01/11] drm/msm: Fix a fence leak in submit error path

by Sasha Levin

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ] In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653584/ Signed-off-by: Rob Clark <robin.clark(a)oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Let me analyze based on what I know from the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Fence Leak Fix ### 1. **Bug Description** The commit fixes a resource leak in the MSM GPU driver's submit error path. When errors occur after `drm_sched_job_arm()` but before `drm_sched_entity_push_job()`, the scheduler fence (`s_fence`) is leaked because `drm_sched_job_cleanup()` is never called. ### 2. **Code Changes Analysis** The fix adds this critical code to `__msm_gem_submit_destroy()`: ```c /* - In error paths, we could unref the submit without calling - drm_sched_entity_push_job(), so msm_job_free() will never - get called. Since drm_sched_job_cleanup() will NULL out - s_fence, we can use that to detect this case. */ if (submit->base.s_fence) drm_sched_job_cleanup(&submit->base); ``` This is a defensive check that ensures proper cleanup of scheduler resources when the submit is destroyed without going through the normal scheduler path. ### 3. **Why This is a Good Backport Candidate** **a) Fixes a Real Bug:** This addresses a concrete resource leak that affects system stability. Each leaked fence consumes memory and other kernel resources that are never freed. **b) Small and Contained:** The fix is minimal - just 9 lines of code including comments. It doesn't change any APIs or data structures. **c) Clear Error Path Fix:** The fix targets a specific error handling path without affecting the normal execution flow. When `drm_sched_entity_push_job()` is called successfully, `msm_job_free()` handles the cleanup as before. **d) Follows Established Patterns:** The fix uses the same pattern as the hw_fence cleanup (checking refcount) that's already in the code, making it consistent with existing error handling. **e) No Architectural Changes:** This is purely a bug fix that plugs a resource leak. It doesn't introduce new features or change behavior. **f) Critical Subsystem:** GPU drivers are important for system stability and user experience. Memory leaks in GPU submission paths can accumulate quickly under heavy graphics workloads. ### 4. **Comparison with Similar Commits** Looking at the similar commits provided: - The first commit (drm/msm: Fix wait_fence submitqueue leak) with backport status YES also fixes a resource leak in error paths - It's similarly small, contained, and fixes a clear bug without architectural changes ### 5. **Risk Assessment** **Low Risk:** - The added check only executes in the destroy path when `s_fence` is non-NULL - If `drm_sched_entity_push_job()` was called, `msm_job_free()` will have already cleaned up `s_fence`, making it NULL - The fix is defensive and won't cause issues even if called unnecessarily ### 6. **Stable Criteria Met** According to stable tree rules: - ✓ Fixes a bug (fence resource leak) - ✓ Minimal change (9 lines) - ✓ Obviously correct (clear logic with explanatory comment) - ✓ Already tested (has Patchwork link indicating review) - ✓ No new features - ✓ Fixes a real issue users could encounter The fence leak could accumulate over time, especially in scenarios with GPU submission failures, leading to memory exhaustion and system instability. This makes it an important fix for stable kernels. drivers/gpu/drm/msm/msm_gem_submit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index fc2fb1019ea1c..2ffb2ca88ffe1 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -76,6 +76,15 @@ void __msm_gem_submit_destroy(struct kref *kref) struct dma_fence *fence; unsigned i; + /* + * In error paths, we could unref the submit without calling + * drm_sched_entity_push_job(), so msm_job_free() will never + * get called. Since drm_sched_job_cleanup() will NULL out + * s_fence, we can use that to detect this case. + */ + if (submit->base.s_fence) + drm_sched_job_cleanup(&submit->base); + if (submit->fence_id) { mutex_lock(&submit->queue->lock); idr_remove(&submit->queue->fence_idr, submit->fence_id); -- 2.39.5

2 months, 3 weeks

1
10
0 0

[PATCH AUTOSEL 6.1 01/15] drm/msm: Fix a fence leak in submit error path

by Sasha Levin

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ] In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653584/ Signed-off-by: Rob Clark <robin.clark(a)oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Let me analyze based on what I know from the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Fence Leak Fix ### 1. **Bug Description** The commit fixes a resource leak in the MSM GPU driver's submit error path. When errors occur after `drm_sched_job_arm()` but before `drm_sched_entity_push_job()`, the scheduler fence (`s_fence`) is leaked because `drm_sched_job_cleanup()` is never called. ### 2. **Code Changes Analysis** The fix adds this critical code to `__msm_gem_submit_destroy()`: ```c /* - In error paths, we could unref the submit without calling - drm_sched_entity_push_job(), so msm_job_free() will never - get called. Since drm_sched_job_cleanup() will NULL out - s_fence, we can use that to detect this case. */ if (submit->base.s_fence) drm_sched_job_cleanup(&submit->base); ``` This is a defensive check that ensures proper cleanup of scheduler resources when the submit is destroyed without going through the normal scheduler path. ### 3. **Why This is a Good Backport Candidate** **a) Fixes a Real Bug:** This addresses a concrete resource leak that affects system stability. Each leaked fence consumes memory and other kernel resources that are never freed. **b) Small and Contained:** The fix is minimal - just 9 lines of code including comments. It doesn't change any APIs or data structures. **c) Clear Error Path Fix:** The fix targets a specific error handling path without affecting the normal execution flow. When `drm_sched_entity_push_job()` is called successfully, `msm_job_free()` handles the cleanup as before. **d) Follows Established Patterns:** The fix uses the same pattern as the hw_fence cleanup (checking refcount) that's already in the code, making it consistent with existing error handling. **e) No Architectural Changes:** This is purely a bug fix that plugs a resource leak. It doesn't introduce new features or change behavior. **f) Critical Subsystem:** GPU drivers are important for system stability and user experience. Memory leaks in GPU submission paths can accumulate quickly under heavy graphics workloads. ### 4. **Comparison with Similar Commits** Looking at the similar commits provided: - The first commit (drm/msm: Fix wait_fence submitqueue leak) with backport status YES also fixes a resource leak in error paths - It's similarly small, contained, and fixes a clear bug without architectural changes ### 5. **Risk Assessment** **Low Risk:** - The added check only executes in the destroy path when `s_fence` is non-NULL - If `drm_sched_entity_push_job()` was called, `msm_job_free()` will have already cleaned up `s_fence`, making it NULL - The fix is defensive and won't cause issues even if called unnecessarily ### 6. **Stable Criteria Met** According to stable tree rules: - ✓ Fixes a bug (fence resource leak) - ✓ Minimal change (9 lines) - ✓ Obviously correct (clear logic with explanatory comment) - ✓ Already tested (has Patchwork link indicating review) - ✓ No new features - ✓ Fixes a real issue users could encounter The fence leak could accumulate over time, especially in scenarios with GPU submission failures, leading to memory exhaustion and system instability. This makes it an important fix for stable kernels. drivers/gpu/drm/msm/msm_gem_submit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index c12a6ac2d3840..4ee6aeb23c512 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -71,6 +71,15 @@ void __msm_gem_submit_destroy(struct kref *kref) container_of(kref, struct msm_gem_submit, ref); unsigned i; + /* + * In error paths, we could unref the submit without calling + * drm_sched_entity_push_job(), so msm_job_free() will never + * get called. Since drm_sched_job_cleanup() will NULL out + * s_fence, we can use that to detect this case. + */ + if (submit->base.s_fence) + drm_sched_job_cleanup(&submit->base); + if (submit->fence_id) { spin_lock(&submit->queue->idr_lock); idr_remove(&submit->queue->fence_idr, submit->fence_id); -- 2.39.5

2 months, 3 weeks

1
14
0 0

[PATCH AUTOSEL 6.6 01/18] drm/msm: Fix a fence leak in submit error path

by Sasha Levin

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ] In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653584/ Signed-off-by: Rob Clark <robin.clark(a)oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Let me analyze based on what I know from the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Fence Leak Fix ### 1. **Bug Description** The commit fixes a resource leak in the MSM GPU driver's submit error path. When errors occur after `drm_sched_job_arm()` but before `drm_sched_entity_push_job()`, the scheduler fence (`s_fence`) is leaked because `drm_sched_job_cleanup()` is never called. ### 2. **Code Changes Analysis** The fix adds this critical code to `__msm_gem_submit_destroy()`: ```c /* - In error paths, we could unref the submit without calling - drm_sched_entity_push_job(), so msm_job_free() will never - get called. Since drm_sched_job_cleanup() will NULL out - s_fence, we can use that to detect this case. */ if (submit->base.s_fence) drm_sched_job_cleanup(&submit->base); ``` This is a defensive check that ensures proper cleanup of scheduler resources when the submit is destroyed without going through the normal scheduler path. ### 3. **Why This is a Good Backport Candidate** **a) Fixes a Real Bug:** This addresses a concrete resource leak that affects system stability. Each leaked fence consumes memory and other kernel resources that are never freed. **b) Small and Contained:** The fix is minimal - just 9 lines of code including comments. It doesn't change any APIs or data structures. **c) Clear Error Path Fix:** The fix targets a specific error handling path without affecting the normal execution flow. When `drm_sched_entity_push_job()` is called successfully, `msm_job_free()` handles the cleanup as before. **d) Follows Established Patterns:** The fix uses the same pattern as the hw_fence cleanup (checking refcount) that's already in the code, making it consistent with existing error handling. **e) No Architectural Changes:** This is purely a bug fix that plugs a resource leak. It doesn't introduce new features or change behavior. **f) Critical Subsystem:** GPU drivers are important for system stability and user experience. Memory leaks in GPU submission paths can accumulate quickly under heavy graphics workloads. ### 4. **Comparison with Similar Commits** Looking at the similar commits provided: - The first commit (drm/msm: Fix wait_fence submitqueue leak) with backport status YES also fixes a resource leak in error paths - It's similarly small, contained, and fixes a clear bug without architectural changes ### 5. **Risk Assessment** **Low Risk:** - The added check only executes in the destroy path when `s_fence` is non-NULL - If `drm_sched_entity_push_job()` was called, `msm_job_free()` will have already cleaned up `s_fence`, making it NULL - The fix is defensive and won't cause issues even if called unnecessarily ### 6. **Stable Criteria Met** According to stable tree rules: - ✓ Fixes a bug (fence resource leak) - ✓ Minimal change (9 lines) - ✓ Obviously correct (clear logic with explanatory comment) - ✓ Already tested (has Patchwork link indicating review) - ✓ No new features - ✓ Fixes a real issue users could encounter The fence leak could accumulate over time, especially in scenarios with GPU submission failures, leading to memory exhaustion and system instability. This makes it an important fix for stable kernels. drivers/gpu/drm/msm/msm_gem_submit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index 018b39546fc1d..27366304f5d59 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -85,6 +85,15 @@ void __msm_gem_submit_destroy(struct kref *kref) container_of(kref, struct msm_gem_submit, ref); unsigned i; + /* + * In error paths, we could unref the submit without calling + * drm_sched_entity_push_job(), so msm_job_free() will never + * get called. Since drm_sched_job_cleanup() will NULL out + * s_fence, we can use that to detect this case. + */ + if (submit->base.s_fence) + drm_sched_job_cleanup(&submit->base); + if (submit->fence_id) { spin_lock(&submit->queue->idr_lock); idr_remove(&submit->queue->fence_idr, submit->fence_id); -- 2.39.5

2 months, 3 weeks

1
17
0 0

[PATCH AUTOSEL 6.12 01/19] drm/msm: Fix a fence leak in submit error path

by Sasha Levin

From: Rob Clark <robdclark(a)chromium.org> [ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ] In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/653584/ Signed-off-by: Rob Clark <robin.clark(a)oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Let me analyze based on what I know from the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Fence Leak Fix ### 1. **Bug Description** The commit fixes a resource leak in the MSM GPU driver's submit error path. When errors occur after `drm_sched_job_arm()` but before `drm_sched_entity_push_job()`, the scheduler fence (`s_fence`) is leaked because `drm_sched_job_cleanup()` is never called. ### 2. **Code Changes Analysis** The fix adds this critical code to `__msm_gem_submit_destroy()`: ```c /* - In error paths, we could unref the submit without calling - drm_sched_entity_push_job(), so msm_job_free() will never - get called. Since drm_sched_job_cleanup() will NULL out - s_fence, we can use that to detect this case. */ if (submit->base.s_fence) drm_sched_job_cleanup(&submit->base); ``` This is a defensive check that ensures proper cleanup of scheduler resources when the submit is destroyed without going through the normal scheduler path. ### 3. **Why This is a Good Backport Candidate** **a) Fixes a Real Bug:** This addresses a concrete resource leak that affects system stability. Each leaked fence consumes memory and other kernel resources that are never freed. **b) Small and Contained:** The fix is minimal - just 9 lines of code including comments. It doesn't change any APIs or data structures. **c) Clear Error Path Fix:** The fix targets a specific error handling path without affecting the normal execution flow. When `drm_sched_entity_push_job()` is called successfully, `msm_job_free()` handles the cleanup as before. **d) Follows Established Patterns:** The fix uses the same pattern as the hw_fence cleanup (checking refcount) that's already in the code, making it consistent with existing error handling. **e) No Architectural Changes:** This is purely a bug fix that plugs a resource leak. It doesn't introduce new features or change behavior. **f) Critical Subsystem:** GPU drivers are important for system stability and user experience. Memory leaks in GPU submission paths can accumulate quickly under heavy graphics workloads. ### 4. **Comparison with Similar Commits** Looking at the similar commits provided: - The first commit (drm/msm: Fix wait_fence submitqueue leak) with backport status YES also fixes a resource leak in error paths - It's similarly small, contained, and fixes a clear bug without architectural changes ### 5. **Risk Assessment** **Low Risk:** - The added check only executes in the destroy path when `s_fence` is non-NULL - If `drm_sched_entity_push_job()` was called, `msm_job_free()` will have already cleaned up `s_fence`, making it NULL - The fix is defensive and won't cause issues even if called unnecessarily ### 6. **Stable Criteria Met** According to stable tree rules: - ✓ Fixes a bug (fence resource leak) - ✓ Minimal change (9 lines) - ✓ Obviously correct (clear logic with explanatory comment) - ✓ Already tested (has Patchwork link indicating review) - ✓ No new features - ✓ Fixes a real issue users could encounter The fence leak could accumulate over time, especially in scenarios with GPU submission failures, leading to memory exhaustion and system instability. This makes it an important fix for stable kernels. drivers/gpu/drm/msm/msm_gem_submit.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index f775638d239a5..937c1f5d88cbb 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -85,6 +85,15 @@ void __msm_gem_submit_destroy(struct kref *kref) container_of(kref, struct msm_gem_submit, ref); unsigned i; + /* + * In error paths, we could unref the submit without calling + * drm_sched_entity_push_job(), so msm_job_free() will never + * get called. Since drm_sched_job_cleanup() will NULL out + * s_fence, we can use that to detect this case. + */ + if (submit->base.s_fence) + drm_sched_job_cleanup(&submit->base); + if (submit->fence_id) { spin_lock(&submit->queue->idr_lock); idr_remove(&submit->queue->fence_idr, submit->fence_id); -- 2.39.5

2 months, 3 weeks

1
18
0 0

[PATCH AUTOSEL 6.15 01/20] x86/platform/amd: move final timeout check to after final sleep

by Sasha Levin

From: Jake Hillion <jake(a)hillion.co.uk> [ Upstream commit f8afb12a2d7503de6558c23cacd7acbf6e9fe678 ] __hsmp_send_message sleeps between result read attempts and has a timeout of 100ms. Under extreme load it's possible for these sleeps to take a long time, exceeding the 100ms. In this case the current code does not check the register and fails with ETIMEDOUT. Refactor the loop to ensure there is at least one read of the register after a sleep of any duration. This removes instances of ETIMEDOUT with a single caller, even with a misbehaving scheduler. Tested on AMD Bergamo machines. Suggested-by: Blaise Sanouillet <linux(a)blaise.sanouillet.com> Reviewed-by: Suma Hegde <suma.hegde(a)amd.com> Tested-by: Suma Hegde <suma.hegde(a)amd.com> Signed-off-by: Jake Hillion <jake(a)hillion.co.uk> Link: https://lore.kernel.org/r/20250605-amd-hsmp-v2-1-a811bc3dd74a@hillion.co.uk Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Bug Analysis The commit fixes a critical race condition in the AMD HSMP driver's timeout handling. The issue occurs in the `__hsmp_send_message()` function where: 1. **Original code flaw**: The loop checks `time_before(jiffies, timeout)` at the start of each iteration, then sleeps, but doesn't check the register one final time after the last sleep completes. 2. **Race condition scenario**: Under heavy system load (as mentioned in the commit message - "Under extreme load"), the sleep operations (`usleep_range()`) can take significantly longer than intended. If the final sleep extends beyond the 100ms timeout window, the code exits with `-ETIMEDOUT` without checking if the SMU actually responded during that extended sleep. 3. **The fix**: Changes the loop from `while (time_before(jiffies, timeout))` to `while (true)` and moves the timeout check to after the register read, ensuring at least one register check occurs after any sleep duration. ## Why This Qualifies for Stable Backport 1. **Fixes a real bug affecting users**: The commit message explicitly states this was "Tested on AMD Bergamo machines" and fixes actual instances of ETIMEDOUT errors. AMD Bergamo is a server processor used in production data centers. 2. **Small, contained fix**: The change is minimal - just restructuring the loop logic without changing functionality. This meets the stable kernel criteria of being a small, obvious fix. 3. **No new features**: This purely fixes existing behavior without adding capabilities. 4. **Critical subsystem**: The HSMP driver is essential for AMD EPYC server management, controlling: - Power management - Thermal monitoring - Performance states - System telemetry 5. **Production impact**: Spurious `-ETIMEDOUT` errors would cause failures in: - Data center management tools - Power capping operations - Performance monitoring - Thermal management 6. **Clear problem and solution**: The race condition is well- understood, and the fix ensures the code behaves as intended - checking the register after sleeping rather than potentially timing out without a final check. ## Risk Assessment The risk is minimal because: - The logic change is straightforward and correct - It's been tested on production AMD Bergamo systems - It only affects the timeout path behavior - The worst case is the same as before (timeout after 100ms) - The best case fixes false timeouts under load This is exactly the type of bug fix that stable kernels exist to deliver - fixing real issues users encounter in production without introducing new risks. drivers/platform/x86/amd/hsmp/hsmp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/amd/hsmp/hsmp.c b/drivers/platform/x86/amd/hsmp/hsmp.c index a3ac09a90de45..ab877112f4c80 100644 --- a/drivers/platform/x86/amd/hsmp/hsmp.c +++ b/drivers/platform/x86/amd/hsmp/hsmp.c @@ -99,7 +99,7 @@ static int __hsmp_send_message(struct hsmp_socket *sock, struct hsmp_message *ms short_sleep = jiffies + msecs_to_jiffies(HSMP_SHORT_SLEEP); timeout = jiffies + msecs_to_jiffies(HSMP_MSG_TIMEOUT); - while (time_before(jiffies, timeout)) { + while (true) { ret = sock->amd_hsmp_rdwr(sock, mbinfo->msg_resp_off, &mbox_status, HSMP_RD); if (ret) { dev_err(sock->dev, "Error %d reading mailbox status\n", ret); @@ -108,6 +108,10 @@ static int __hsmp_send_message(struct hsmp_socket *sock, struct hsmp_message *ms if (mbox_status != HSMP_STATUS_NOT_READY) break; + + if (!time_before(jiffies, timeout)) + break; + if (time_before(jiffies, short_sleep)) usleep_range(50, 100); else -- 2.39.5

2 months, 3 weeks

1
19
0 0

[PATCH] lib/crypto: mips/chacha: Fix clang build and remove unneeded byteswap

by Eric Biggers

The MIPS32r2 ChaCha code has never been buildable with the clang assembler. First, clang doesn't support the 'rotl' pseudo-instruction: error: unknown instruction, did you mean: rol, rotr? Second, clang requires that both operands of the 'wsbh' instruction be explicitly given: error: too few operands for instruction To fix this, align the code with the real instruction set by (1) using the real instruction 'rotr' instead of the nonstandard pseudo- instruction 'rotl', and (2) explicitly giving both operands to 'wsbh'. To make removing the use of 'rotl' a bit easier, also remove the unnecessary special-casing for big endian CPUs at .Lchacha_mips_xor_bytes. The tail handling is actually endian-independent since it processes one byte at a time. On big endian CPUs the old code byte-swapped SAVED_X, then iterated through it in reverse order. But the byteswap and reverse iteration canceled out. Tested with chacha20poly1305-selftest in QEMU using "-M malta" with both little endian and big endian mips32r2 kernels. Fixes: 49aa7c00eddf ("crypto: mips/chacha - import 32r2 ChaCha code from Zinc") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505080409.EujEBwA0-lkp@intel.com/ Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- This applies on top of other pending lib/crypto patches and can be retrieved from git at: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git mips-chacha-fix lib/crypto/mips/chacha-core.S | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/lib/crypto/mips/chacha-core.S b/lib/crypto/mips/chacha-core.S index 5755f69cfe007..706aeb850fb0d 100644 --- a/lib/crypto/mips/chacha-core.S +++ b/lib/crypto/mips/chacha-core.S @@ -53,21 +53,17 @@ #define IS_UNALIGNED $s7 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ #define MSB 0 #define LSB 3 -#define ROTx rotl -#define ROTR(n) rotr n, 24 #define CPU_TO_LE32(n) \ - wsbh n; \ + wsbh n, n; \ rotr n, 16; #else #define MSB 3 #define LSB 0 -#define ROTx rotr #define CPU_TO_LE32(n) -#define ROTR(n) #endif #define FOR_EACH_WORD(x) \ x( 0); \ x( 1); \ @@ -190,14 +186,14 @@ CONCAT3(.Lchacha_mips_xor_aligned_, PLUS_ONE(x), _b: ;) \ addu X(D), X(N); \ xor X(V), X(A); \ xor X(W), X(B); \ xor X(Y), X(C); \ xor X(Z), X(D); \ - rotl X(V), S; \ - rotl X(W), S; \ - rotl X(Y), S; \ - rotl X(Z), S; + rotr X(V), 32 - S; \ + rotr X(W), 32 - S; \ + rotr X(Y), 32 - S; \ + rotr X(Z), 32 - S; .text .set reorder .set noat .globl chacha_crypt_arch @@ -370,25 +366,23 @@ chacha_crypt_arch: addu IN, $at addu OUT, $at /* First byte */ lbu T1, 0(IN) addiu $at, BYTES, 1 - CPU_TO_LE32(SAVED_X) - ROTR(SAVED_X) xor T1, SAVED_X sb T1, 0(OUT) beqz $at, .Lchacha_mips_xor_done /* Second byte */ lbu T1, 1(IN) addiu $at, BYTES, 2 - ROTx SAVED_X, 8 + rotr SAVED_X, 8 xor T1, SAVED_X sb T1, 1(OUT) beqz $at, .Lchacha_mips_xor_done /* Third byte */ lbu T1, 2(IN) - ROTx SAVED_X, 8 + rotr SAVED_X, 8 xor T1, SAVED_X sb T1, 2(OUT) b .Lchacha_mips_xor_done .Lchacha_mips_no_full_block_unaligned: -- 2.50.0

2 months, 3 weeks

1
1
0 0

[PATCH v4 0/2] Fix DR6/DR7 initialization

by Xin Li (Intel)

Sohil reported seeing a split lock warning when running a test that generates userspace #DB: x86/split lock detection: #DB: sigtrap_loop_64/4614 took a bus_lock trap at address: 0x4011ae We investigated the issue and figured out: 1) The warning is a false positive. 2) It is not caused by the test itself. 3) It occurs even when Bus Lock Detection (BLD) is disabled. 4) It only happens on the first #DB on a CPU. And the root cause is, at boot time, Linux zeros DR6. This leads to different DR6 values depending on whether the CPU supports BLD: 1) On CPUs with BLD support, DR6 becomes 0xFFFF07F0 (bit 11, DR6.BLD, is cleared). 2) On CPUs without BLD, DR6 becomes 0xFFFF0FF0. Since only BLD-induced #DB exceptions clear DR6.BLD and other debug exceptions leave it unchanged, even if the first #DB is unrelated to BLD, DR6.BLD is still cleared. As a result, such a first #DB is misinterpreted as a BLD #DB, and a false warning is triggerred. Fix the bug by initializing DR6 by writing its architectural reset value at boot time. DR7 suffers from a similar issue, apply the same fix. This patch set is based on tip/x86/urgent branch as of today. Link to the previous patch set v3: https://lore.kernel.org/all/20250618172723.1651465-1-xin@zytor.com/ Change in v4: *) Cc stable in the DR7 initialization patch for backporting, just in case bit 10 of DR7 has become unreserved on new hardware, even though clearing it doesn't currently cause any real issues (Dave Hansen). Xin Li (Intel) (2): x86/traps: Initialize DR6 by writing its architectural reset value x86/traps: Initialize DR7 by writing its architectural reset value arch/x86/include/asm/debugreg.h | 19 ++++++++++++---- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/include/uapi/asm/debugreg.h | 21 ++++++++++++++++- arch/x86/kernel/cpu/common.c | 24 ++++++++------------ arch/x86/kernel/kgdb.c | 2 +- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kernel/traps.c | 34 +++++++++++++++++----------- arch/x86/kvm/x86.c | 4 ++-- 9 files changed, 72 insertions(+), 38 deletions(-) base-commit: 2aebf5ee43bf0ed225a09a30cf515d9f2813b759 -- 2.49.0

2 months, 3 weeks

4
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror