[PATCH AUTOSEL 6.19-6.6] thermal: int340x: Fix sysfs group leak on DLVR registration failure

[Sasha Levin]

From: Kaushlendra Kumar <kaushlendra.kumar@xxxxxxxxx>

[ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ]

When DLVR sysfs group creation fails in proc_thermal_rfim_add(),
the function returns immediately without cleaning up the FIVR group
that may have been created earlier.

Add proper error unwinding to remove the FIVR group before returning
failure.

Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@xxxxxxxxx>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete understanding of the code. Let me do a final check
on the existing error handling in the DVFS section, which already had
cleanup for FIVR and DLVR (but note: the DVFS section also has a bug -
it returns after removing FIVR but doesn't also remove DLVR, and vice
versa. However, that's a separate issue).

## Analysis

### 1. Commit Message Analysis
The commit message clearly describes a **resource leak bug fix**: when
DLVR sysfs group creation fails, the previously created FIVR sysfs group
is not cleaned up. The fix adds proper error unwinding.

### 2. Code Change Analysis
The bug is straightforward and real:

In `proc_thermal_rfim_add()`:
1. First, the FIVR sysfs group is created (line 447)
2. Then, the DLVR sysfs group is created (line 468)
3. If the DLVR creation fails (line 469), the code returns immediately
   **without** removing the FIVR group

The fix adds a conditional cleanup: if FIVR was created (checked via
`PROC_THERMAL_FEATURE_FIVR` mask) and DLVR creation fails, remove the
FIVR group before returning the error.

Interestingly, the DVFS section (lines 473-482) already had similar
cleanup logic (removing both FIVR and DLVR on DVFS failure), showing the
author's intent was always to have proper unwinding. The DLVR section
was simply missing the same pattern.

### 3. Classification
- **Bug type**: Resource leak (sysfs group leak on error path)
- **Severity**: Low-to-medium. A leaked sysfs group during probe failure
  could lead to:
  - Stale sysfs entries
  - Issues on subsequent probe attempts
  - Resource leak
- **Fix correctness**: Obviously correct. The pattern matches what's
  already done in the DVFS error handling section of the same function.

### 4. Scope and Risk Assessment
- **Change size**: +3 lines changed (adding cleanup in one error path)
- **Files touched**: 1 file
- **Risk**: Very low. The fix only adds cleanup that mirrors existing
  patterns in the same function.
- **Regression potential**: Extremely low - removing a sysfs group that
  was just created in a failure path cannot break anything.

### 5. Stable Kernel Rules Compliance
- **Obviously correct**: Yes, the pattern is identical to existing
  cleanup in the DVFS section
- **Fixes a real bug**: Yes, a sysfs group resource leak on error path
- **Small and contained**: Yes, 3 lines in 1 file
- **No new features**: Correct, pure bug fix
- **Tested**: Acked by the subsystem maintainer (Srinivas Pandruvada)

### 6. Affected Versions
The DLVR feature was introduced in commit 5bc6b1df65c87 (v6.4..v6.5
cycle), so this bug affects kernels v6.5 and later. Current stable trees
that would need this: 6.6.y, 6.12.y (and possibly others depending on
active stable branches).

### Verification
- `git log --oneline` on the file confirmed commit history and that the
  fix is 15176b818e048
- `git show 5bc6b1df65c87` confirmed DLVR support was added in the
  v6.4→v6.5 window, introducing the buggy error path
- Read of `processor_thermal_rfim.c` lines 442-486 confirmed the pre-fix
  code: DLVR error path at line 469-470 returns without FIVR cleanup
- Read confirmed DVFS section (lines 473-482) already had the cleanup
  pattern the DLVR section was missing
- `git tag --contains 5bc6b1df65c87` confirmed affected versions start
  at v6.5 era
- Commit is Acked-by Srinivas Pandruvada (Intel thermal subsystem
  maintainer), confirming correctness

### Conclusion
This is a textbook stable backport candidate: a small, obvious resource
leak fix on an error path, with minimal risk, acked by the subsystem
maintainer, and following an existing pattern in the same function. It
affects Intel thermal driver users on platforms with both FIVR and DLVR
features when DLVR probe fails.

**YES**

 .../thermal/intel/int340x_thermal/processor_thermal_rfim.c   | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
index 589a3a71f0c4c..ba88d878c998d 100644
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
@@ -466,8 +466,11 @@ int proc_thermal_rfim_add(struct pci_dev *pdev, struct proc_thermal_device *proc
 			break;
 		}
 		ret = sysfs_create_group(&pdev->dev.kobj, &dlvr_attribute_group);
-		if (ret)
+		if (ret) {
+			if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_FIVR)
+				sysfs_remove_group(&pdev->dev.kobj, &fivr_attribute_group);
 			return ret;
+		}
 	}
 
 	if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_DVFS) {
-- 
2.51.0