iter10 Phase 0: Bommarito patch unreachable on RK3399 — close Phase 0 negative
Empirical reachability check on linux-fresnel-fourier 7.0-1 source tree at boltzmann:~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/.../linux-7.0/. rkvdec_hevc_assemble_hw_rps() is defined in rkvdec-hevc-common.c:411 and called ONLY from rkvdec-vdpu381-hevc.c:609 (RK3576) and rkvdec-vdpu383-hevc.c:620 (RK3588). RK3399's variant_ops bind to rockchip,rk3399-vdec and route HEVC through the older standalone rkvdec-hevc.c, which does NOT call rkvdec_hevc_assemble_hw_rps. Bommarito's May 13 patch is real and load-bearing on RK3588/3576, but inert on RK3399 / fresnel. Not iter10 vehicle for Bug 5. Saved a kernel build/reboot cycle by Phase-0 reachability check. Memory rule candidate: before applying any upstream patch to fresnel's kernel, verify the patched path is reachable from rockchip,rk3399-vdec. mainline rkvdec has diverging per-variant code (VDPU381/383 vs RK3399 legacy). iter10 candidate pivots: - α-10: audit rkvdec-hevc.c (RK3399 legacy) for analogous OOB gaps; same KUnit/KASAN methodology Bommarito used. Route via kernel-agent per user directive. - α-12: stay on Bug 4 H.264 (PPS deep diff / OUTPUT bitstream). User directive registered: "consult kernel-agent for kernel work." Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,74 @@
|
||||
# Iteration 10 — Phase 0 (substrate / motivation / inventory) → Phase 1 lock
|
||||
|
||||
Opens 2026-05-14 after iter9 PARTIAL close ([`phase8_iteration9_close.md`](phase8_iteration9_close.md), commit `5e2a228`). User pointed me at Michael Bommarito's May 13, 2026 patch on linux-rockchip:
|
||||
|
||||
> `[PATCH] media: rkvdec: hevc: cap EXT SPS RPS control counts before descriptor assembly`
|
||||
> Message-ID: `<20260513181922.2075438-1-michael.bommarito@gmail.com>`
|
||||
> Assisted-by: Claude:claude-opus-4-7
|
||||
|
||||
iter10 Phase 0 task: evaluate whether this kernel-side bounds-check patch fixes Bug 5 (HEVC libva all-zero) on fresnel.
|
||||
|
||||
## Empirical reachability check
|
||||
|
||||
The patch adds `rkvdec_hevc_validate_rps_ctrls()` and calls it at the entry of `rkvdec_hevc_assemble_hw_rps()` in `drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:411`.
|
||||
|
||||
Reachability on fresnel (RK3399, `rockchip,rk3399-vdec`):
|
||||
|
||||
```
|
||||
$ grep -rn rkvdec_hevc_assemble_hw_rps drivers/media/platform/rockchip/rkvdec/
|
||||
rkvdec-hevc-common.c:411 void rkvdec_hevc_assemble_hw_rps(...) { ... } # definition
|
||||
rkvdec-hevc-common.h:96 void rkvdec_hevc_assemble_hw_rps(...); # header
|
||||
rkvdec-vdpu381-hevc.c:609 rkvdec_hevc_assemble_hw_rps(...) # RK3576 caller
|
||||
rkvdec-vdpu383-hevc.c:620 rkvdec_hevc_assemble_hw_rps(...) # RK3588 caller
|
||||
```
|
||||
|
||||
The function is referenced **only** from the VDPU381 (RK3576) and VDPU383 (RK3588) variant glue. The RK3399 variant operations (`rk3399_variant_ops` in `rkvdec.c:1657`) bind to `rockchip,rk3399-vdec` (DT compatible at line 1752) and the RK3399 HEVC path lives in the older `rkvdec-hevc.c`, which does **not** call `rkvdec_hevc_assemble_hw_rps`.
|
||||
|
||||
**Conclusion**: Bommarito's patch is reachable on RK3588 / RK3576, not on RK3399. **It does not fix Bug 5 on fresnel.**
|
||||
|
||||
This matches Bommarito's own commit log:
|
||||
> "I don't have a RK3588 / RK3576 board to confirm this through a real /dev/videoN request path yet, but was convinced enough by [KUnit harness]."
|
||||
|
||||
The patch is real and load-bearing on the RK3588/3576 path — but irrelevant to our hardware.
|
||||
|
||||
## Implications for the campaign
|
||||
|
||||
1. The May 13 patch is **not an iter10 candidate** for fresnel.
|
||||
2. Bug 5 (HEVC libva all-zero) on fresnel is in a different code path: `rkvdec-hevc.c` (the RK3399 standalone HEVC handler). That's what would need to be investigated for a kernel-side Bug 5 fix.
|
||||
3. The Bommarito patch is still useful as **methodology reference**: KUnit harness around the existing helper, KASAN-detect OOB writes, then add bounds check. Same shape could be applied to the RK3399 HEVC path in `rkvdec-hevc.c` if we suspect a similar OOB write is happening there.
|
||||
|
||||
## iter10 candidate pivots
|
||||
|
||||
Three candidates after Bommarito unreachability is confirmed:
|
||||
|
||||
- **α-10**: Audit the RK3399 HEVC kernel path (`rkvdec-hevc.c`) for analogous bounds-check gaps. If libva's HEVC controls submit out-of-range count fields, we may be triggering a silent OOB write that explains Bug 5's all-zero output. Same KUnit/KASAN methodology as Bommarito.
|
||||
- **α-11**: Apply Bommarito's patch anyway (no-op on RK3399 since unreachable, but ships hygiene). Skip — pure busywork.
|
||||
- **α-12**: Stay on Bug 4 H.264 (iter9 close ranked: PPS deep diff, OUTPUT bitstream byte inspection, DPB ordering, slice-data encoding).
|
||||
|
||||
User directive carries: "consult kernel-agent for kernel work" → α-10 (if pursued) routes through kernel-agent for source / build / promote.
|
||||
|
||||
## Substrate state at iter10 open
|
||||
|
||||
- Fork tip `e0be4e6` (iter9 close) on noether + fresnel + gitea.
|
||||
- Backend SHA `a17e3c39…` on fresnel (iter8+iter9 hygiene cleanups: γ + IMP-1 + α-2 + α-7).
|
||||
- Kernel `linux-fresnel-fourier 7.0-1` unchanged (mmind v7.0 + 3 PBP DTS).
|
||||
- Kernel source on boltzmann: `~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/linux-fresnel-fourier/src/linux-7.0/`.
|
||||
- All diagnostic instrumentation (γ + memset gate) preserved.
|
||||
|
||||
## Locked research question (iter10, 2026-05-14)
|
||||
|
||||
Phase 0 conclusion: Bommarito patch is **not the iter10 vehicle**. iter10 PASS condition for this Phase 0 alone is simply **"establish whether the Bommarito patch is reachable on fresnel: no."** That's done.
|
||||
|
||||
iter10 continues by picking a fresh research question — defer to user direction or proceed with α-10 / α-12.
|
||||
|
||||
## Phase 8 wrap (early)
|
||||
|
||||
This Phase 0 closes with a definitive negative finding. iter10 doesn't need a Phase 1-7 loop because the candidate was eliminated at Phase 0 by reachability analysis.
|
||||
|
||||
Net: **eliminated one kernel-side hypothesis for Bug 5 cleanly without burning a kernel build cycle.** Source-read on boltzmann's kernel-agent tree was sufficient.
|
||||
|
||||
Memory rule worth recording: **before applying any upstream patch to fresnel's kernel, verify the patched code path is reachable from `rockchip,rk3399-vdec`**. The mainline rkvdec tree has diverging per-variant code (VDPU381/383 vs RK3399 legacy) and patches targeting one variant don't apply to the other.
|
||||
|
||||
## Next moves
|
||||
|
||||
Pending user direction. Default: continue with α-12 (Bug 4 H.264, the iter9 ranked candidates) until kernel work for Bug 5 is explicitly invoked.
|
||||
Reference in New Issue
Block a user