[PATCH AUTOSEL 6.19-5.10] drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback

[Sasha Levin <sashal@kernel.org>]

From: Ludovic Desroches <ludovic.desroches@microchip.com>

[ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ]

After several commits, the slab memory increases. Some drm_crtc_commit
objects are not freed. The atomic_destroy_state callback only put the
framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function
to put all the objects that are no longer needed.

It has been seen after hours of usage of a graphics application or using
kmemleak:

unreferenced object 0xc63a6580 (size 64):
  comm "egt_basic", pid 171, jiffies 4294940784
  hex dump (first 32 bytes):
    40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6  @P4..........e:.
    8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6  .e:......e:..e:.
  backtrace (crc c25aa925):
    kmemleak_alloc+0x34/0x3c
    __kmalloc_cache_noprof+0x150/0x1a4
    drm_atomic_helper_setup_commit+0x1e8/0x7bc
    drm_atomic_helper_commit+0x3c/0x15c
    drm_atomic_commit+0xc0/0xf4
    drm_atomic_helper_set_config+0x84/0xb8
    drm_mode_setcrtc+0x32c/0x810
    drm_ioctl+0x20c/0x488
    sys_ioctl+0x14c/0xc20
    ret_fast_syscall+0x0/0x54

Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of drm/atmel-hlcdc: fix memory leak from
atomic_destroy_state callback

### 1. Commit Message Analysis

The commit message is explicit and well-documented:
- **Subject clearly states "fix memory leak"** - this is a bug fix
- **Detailed explanation**: `drm_crtc_commit` objects are not being
  freed because the `atomic_destroy_state` callback only puts the
  framebuffer, but doesn't clean up other objects held in the plane
  state
- **Includes kmemleak backtrace** - the bug is reproducible and
  confirmed with a kernel debugging tool
- **Real-world impact described**: "seen after hours of usage of a
  graphics application" - this affects actual users running graphical
  applications on Atmel/Microchip SoCs
- **Reviewed-by tag** from the subsystem maintainer

### 2. Code Change Analysis

The fix is extremely small and surgical - it replaces a manual
`drm_framebuffer_put()` call with
`__drm_atomic_helper_plane_destroy_state()`.

**What was wrong:**
```c
// OLD - only freed the framebuffer reference
if (s->fb)
    drm_framebuffer_put(s->fb);
```

**What the fix does:**
```c
// NEW - properly cleans up ALL objects in the plane state
__drm_atomic_helper_plane_destroy_state(s);
```

The function `__drm_atomic_helper_plane_destroy_state()` is the standard
DRM helper that properly releases all resources associated with a plane
state, including:
- The framebuffer reference (what was already done)
- The fence
- The `drm_crtc_commit` object (what was being leaked)
- Any other state tracked by the DRM core

This is a textbook case of a driver not using the standard helper
function, leading to incomplete cleanup and memory leaks. The
`drm_crtc_commit` objects accumulate over time, consuming slab memory.

### 3. Classification

- **Bug type**: Memory leak (resource leak)
- **Severity**: Medium-high - progressive memory consumption over hours
  of use eventually impacts system stability
- **Category**: Missing cleanup in a standard callback that should use
  the DRM helper function

### 4. Scope and Risk Assessment

- **Lines changed**: 3 lines (2 removed, 1 added) - extremely minimal
- **Files changed**: 1 file only
- **Risk**: Very low - `__drm_atomic_helper_plane_destroy_state()` is a
  well-established DRM core helper function used by virtually all DRM
  drivers. It's a superset of what was already being done (framebuffer
  put), plus proper cleanup of other state objects. This is not
  introducing new behavior; it's completing the cleanup that should have
  always been done.
- **Could it break something?** Extremely unlikely. The helper function
  does exactly what the old code did (put framebuffer) plus additional
  necessary cleanup.

### 5. User Impact

- **Affected users**: Anyone using the Atmel HLCDC display controller
  (common in Microchip/Atmel SAM series SoCs used in embedded systems)
- **Symptoms**: Gradual memory consumption increase during graphics
  usage, eventually leading to OOM or degraded system performance
- **Trigger**: Normal graphics usage over time - this is a hot path hit
  on every atomic commit
- **Severity if triggered**: Memory leak in a frequently-called path
  leads to eventual system degradation or OOM

### 6. Stability Indicators

- **Reviewed-by** from subsystem maintainer (Manikandan Muralidharan)
- Uses a standard, well-tested DRM helper function
- The fix pattern (replacing manual cleanup with the proper helper) is a
  very common and well-understood DRM fix

### 7. Dependency Check

- `__drm_atomic_helper_plane_destroy_state()` has been available in the
  DRM subsystem for many years (since 2015+), so it exists in all active
  stable trees
- No dependency on other patches - this is a self-contained fix

### 8. Stable Kernel Rules Compliance

1. **Obviously correct and tested**: Yes - uses the standard helper,
   confirmed with kmemleak
2. **Fixes a real bug**: Yes - memory leak confirmed with kmemleak and
   observed in production use
3. **Important issue**: Yes - progressive memory leak in a hot path
   affecting embedded systems
4. **Small and contained**: Yes - 3-line change in a single file
5. **No new features**: Correct - pure bug fix
6. **Applies cleanly**: Should apply cleanly as this is a driver-
   specific change in a stable file

### Summary

This is a clear-cut memory leak fix. It's small, surgical, uses a
standard helper function, has been confirmed with kmemleak, affects real
users running graphics applications on Atmel/Microchip embedded
hardware, and carries virtually no regression risk. It meets all stable
kernel backport criteria.

**YES**

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 0ffec44c6d317..c0075894dc422 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -1190,8 +1190,7 @@ static void atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
 			      state->dscrs[i]->self);
 	}
 
-	if (s->fb)
-		drm_framebuffer_put(s->fb);
+	__drm_atomic_helper_plane_destroy_state(s);
 
 	kfree(state);
 }
-- 
2.51.0