kellito
9846f288b4
The Mesa Redox winsys CS submit path at src/gallium/winsys/redox/drm/redox_drm_cs.c:156 faked the seqno with 'result.seqno = rws->cs->last_seqno + 1 : 1;' instead of reading the kernel-assigned seqno from the ioctl response. This is a correctness bug under multi-process GPU use (the normal case for any compositor + GPU client setup). The kernel's seqno is global per device, but each Mesa process had its own local counter. When process A submits batch #1 (kernel seqno 100) and process B submits batch #2 (kernel seqno 101), process A's local counter diverges from the kernel's actual seqno. Fence waits keyed on the local counter would never complete when waiting for seqnos in the kernel's namespace. Fix (three coordinated changes): ### 1. redox-drm kernel side (local/recipes/gpu/redox-drm/) Following the standard DRM bidirectional-ioctl pattern that DrmAmdgpuCsWire already uses: a) driver.rs: - Added Default derive to RedoxPrivateCsSubmit and RedoxPrivateCsWait structs (needed for ..Default::default() at construction sites). - Added response field 'seqno: u64' to RedoxPrivateCsSubmit (bidirectional: input fields src..byte_count, output seqno). - Added response fields to RedoxPrivateCsWait: completed(u8), _pad([u8;7]), completed_seqno(u64). - Updated size tests: Submit 32->40 bytes, Wait 16->32 bytes. - Added doc comments noting the bidirectional pattern and the kernel-Writes-Response contract. b) scheme.rs: - CS_SUBMIT handler writes resp.seqno back into req.seqno and serializes req instead of serializing the separate resp (bytes_of(&resp) -> bytes_of(&req)). This is the kernel returning the response in the same struct. - CS_WAIT handler similarly copies result fields into req. - req made mutable for in-place mutation before serialization. - All other places that construct these structs use ..Default::default() for the new response fields. c) drivers/amd/mod.rs, intel/mod.rs, virtio/mod.rs: - Each cs_submit and cs_wait construction site now uses ..Default::default() for the new response fields. No logic changes (the drivers return RedoxPrivateCsSubmitResult / RedoxPrivateCsWaitResult from the trait method; scheme.rs copies the response into the bidirectional struct). ### 2. Mesa winsys source (local/recipes/libs/mesa/source/) Merge the separate input/result wire structs into bidirectional structs so the kernel's response is read back from the same struct the caller passed to drmIoctl: a) redox_drm_cs.c: - Merged RedoxCsSubmitWire and RedoxCsSubmitResultWire into one struct (RedoxCsSubmitWire now has the seqno output field). - Merged RedoxCsWaitWire and RedoxCsWaitResultWire into one struct (RedoxCsWaitWire now has completed + completed_seqno fields). - Removed 'result.seqno = rws->cs->last_seqno + 1 : 1;' fake. Instead, reads 'submit.seqno' and 'wait.completed_seqno' from the same struct after drmIoctl returns. - Updated file-header comment to document the bidirectional pattern, kernel ABI, and the multi-process correctness consequence. b) Patches the durability: - Added 'mesa/26-cs-submit-bidirectional-seqno.patch' to the patches list in local/recipes/libs/mesa/recipe.toml. - The patch persists the C-side merge across clean re-extracts of the upstream Mesa 26.1.4 tarball. Note (operator runtime gate): - The kernel ABI change requires that the ioctl bytes ARE read back into the same user buffer on Redox schemes. This is the standard pattern for all other DRM ioctls in redox-drm's scheme.rs (DrmGemCreateWire, DrmAmdgpuCsWire, DrmCreateDumbWire etc.). Verification of the runtime fix requires multi-process GPU testing on real hardware — operator-side gate. - Per AGENTS.md NO-FALLBACK policy: this fixes a real correctness bug. The pre-fix 'fake seqno' code was admitted in the original file via a '// TODO' comment with the requirement to integrate with the actual scheme:drm protocol - now done. Files changed: - local/recipes/gpu/redox-drm/source/src/driver.rs - local/recipes/gpu/redox-drm/source/src/scheme.rs - local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs - local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs - local/recipes/gpu/redox-drm/source/src/drivers/virtio/mod.rs - local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/redox_drm_cs.c - local/recipes/libs/mesa/recipe.toml - local/patches/mesa/26-cs-submit-bidirectional-seqno.patch
local/patches/ — patch archive structure
Last updated: 2026-07-12 (Round 7) Status: Build system at 100% patch preservation. 121 active patches + 159 archived = 280 total cataloged patches.
Layout
local/patches/
├── README.md # this file
├── <comp>/ # ACTIVE patches (121)
│ ├── <fork>/ # base, kernel, relibc, ...
│ │ ├── P3-*.patch # applied by cookbook
│ │ └── redox.patch # legacy all-in-one (gitignored)
│ ├── <fork>/absorbed/ # historical snapshots
│ │ └── P3-*.patch # PATCHES BEFORE they were committed
│ │ # to fork via mega-absorption. Recoverable.
│ └── <fork>/.gitignore'd # cargo metadata etc
├── legacy-superseded-2026-07-12/ # Round 2-6 archive (97)
│ ├── README + SUPERSEDED.md # per-component audit log
│ ├── base/, kernel/, relibc/, redoxfs/, userutils/
│ └── P3-*.patch # classified-SUPERSEDED
└── legacy-absorbed-2026-07-12/ # Round 2-3 archive (62)
├── README + SUPERSEDED.md # per-component audit log
├── base/, kernel/, relibc/, userutils/
└── P3-*.patch # classified-INTEGRATED
What's an "absorbed" patch?
A patch is moved to legacy-absorbed-2026-07-12/ when Round 2-3's
supersession classifier determined that the same fix is already
committed to the fork's HEAD under a different commit subject. The
.patch file is preserved as historical documentation but is no longer
applied during build. This is operator-supersession under AGENTS.md
"Upstream-first rule for fast-moving components".
The patch's content IS in the fork. Re-applying would either:
- Be a no-op (
patch -Nfor already-applied) — safe - Cause a real conflict (if fork content has since evolved past the patch's intent) — operator decision needed
What's a "superseded" patch?
A patch is moved to legacy-superseded-2026-07-12/ when its content
is no longer needed at all — either:
- Upstream Redox's newer tag already provides equivalent functionality (canonical "upstream preferred" path)
- The fork's file structure has been rebased past the patch's expectations (file-restructured)
- The operator cleaned up the corresponding code as part of a refactor (operator-superseded)
The patch's content is NOT in the fork. Re-applying would create unintended work. Recovery: rebase fork onto newer upstream or accept the operator's refactor.
How to recover a patch
# Move patch back to active location
cp local/patches/legacy-superseded-2026-07-12/<comp>/<patch>.patch \
local/patches/<comp>/
# Optionally try applying it (will probably be a no-op for INTEGRATED,
# may fail for SUPERSEDED)
cd local/sources/<comp>
git apply --check -N -p1 < ../../local/patches/<comp>/<patch>.patch
Tooling
The patch audit tool runs as part of pre-push-checks.sh:
./local/scripts/pre-push-checks.sh
The 5 checks are: sync-versions, verify-fork-versions,
verify-patch-content, verify-collision-detection, and the collision
selftest. All must pass for the pre-push hook to allow a git push.
For a full operator-decision guide on what to do with new orphans,
see local/docs/legacy-obsolete-2026-07-25/PATCH-PRESERVATION-AUDIT-2026-07-12.md (the "Out-of-
scope" section tracks the current Round 5+6 forward work).
Round 7 snapshot
| Directory | Count | Source |
|---|---|---|
*/ (active) |
121 | operator's working fork state |
legacy-superseded-2026-07-12/ |
97 | Round 2-6 SUPERSEDED audits |
legacy-absorbed-2026-07-12/ |
62 | Round 2-3 INTEGRATED audits |
legacy-recipe-patches/ |
0 | (deleted in Round 1.2; not a separate dir anymore) |
| Total cataloged | 280 |
Notes
- Each legacy/ directory has its own SUPERSEDED.md audit log with per-component tables of what was archived, when, and why.
- The
absorbed/subdir under each active component (base/absorbed/,relibc/absorbed/) was removed in Round 3.0; its content was consolidated intolegacy-absorbed-2026-07-12/<comp>/. Theabsorbed/under each component's recipe was Round 2's experimental split. - New orphans detected by
verify-patch-content.share NOT automatically archived — that's an operator decision. Seelocal/scripts/verify-patch-content.sh --help(no current options; future work: add a--auto-archivemode).