Skip to content

mesa-m3: catch Bash append overrides during system handoff - #213

Open
chriskearney wants to merge 1 commit into
integration/aurorafrom
fix/mesa-m3-append-overrides-20261025
Open

chriskearney wants to merge 1 commit into
integration/aurorafrom
fix/mesa-m3-append-overrides-20261025

Conversation

@chriskearney

@chriskearney chriskearney commented Oct 25, 2026 •

Copy link
Copy Markdown
Collaborator

A late uwsm line such as export LIBGL_ALWAYS_SOFTWARE+=1 passes the merged #211 scanner as user_setup=none, but Bash accepts it even in POSIX mode and enables software rendering. LD_LIBRARY_PATH+=/another/provider is missed the same way. The clean-environment probe can therefore pass before the desktop gets a different setting.

In --system-provider mode, report tracked Bash append assignments as unknown and keep the existing software fallback. The default legacy parser is unchanged, and unrelated appends remain allowed. Bump mesa-m3 to 26.1.4.m3.2-8 and refresh its detector checksum.

Validation at 5a4d693:

  • 22 provider tests pass, including real Bash POSIX execution of both missed assignments and strict refusal afterward.
  • Full handoff suite: 219 passing checks under each of sh and Bash; the new late-append cases refuse before the native helper runs.
  • Existing legacy user-setup suite: 51 checks pass. Recipe checksum alignment, shell syntax and git diff --check pass.

Follow-up to #211, based on integration including #212. The exact -8 recipe built successfully in a native aarch64 VM, including its existing shader/compiler and package checks. Artifact SHA256: c8018060cc29a5acc180bfc639f7c0c43ff4ba5607ac2656b0ec61c25ddf6d4a; extracted detector matches this source. No hardware, kernel, firmware, boot or CODEOWNERS changes. These host checks do not qualify the pending fresh M3 login/image handoff.

Bash accepts NAME+=VALUE in POSIX mode, but the scanner only recognizes
NAME=VALUE. A late uwsm export such as LIBGL_ALWAYS_SOFTWARE+=1 therefore
passes the system-provider check before selecting software rendering.

Report tracked append assignments as unknown in system-provider mode,
keeping the software recovery path. Leave the default legacy scanner
unchanged. Exercise Bash's actual result and the complete handoff under
both shells, and bump the package release with its updated checksum.

Generated-by: LLM
Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com>
@chriskearney

chriskearney commented Oct 25, 2026 •

Copy link
Copy Markdown
Collaborator Author

Native package validation completed for 5a4d6937a4d8e8dd5a837647bb4dcb3052c914cd.

  • Build b1025-040632-823f: success, 6m36s. All 31 source checksums and the unchanged recipe’s qualified shader/compiler, queue/TLS, derived-dependency and packaging checks pass.

  • Artifact: mesa-m3-26.1.4.m3.2-8-aarch64.pkg.tar.zst, SHA256 c8018060cc29a5acc180bfc639f7c0c43ff4ba5607ac2656b0ec61c25ddf6d4a.

  • Extracted detector matches this source, SHA256 04fae9bf32a09a574b6ed9ab9d7afb97340df252b9269ed789303e8561a61a21. The hook, user-setup list and AArch64 helper match their source/expected package paths; helper mode is 0755. No boot payload is present.

  • 22 provider tests and 219 full handoff checks under each shell pass, including real Bash POSIX execution of both missed append forms, strict unknown refusal, unchanged legacy behavior and the unrelated-append control. The existing legacy detector suite’s 51 checks pass.

  • Independent read-only review reproduced the missed assignments on the merged mesa-m3: allow checked system Mesa after a file opt-out #211 source and confirmed that uwsm sources those shell files after the global hook. The correction matches the assignment word, so it also catches that word after a declaration builtin.

  • Full GitHub CI: success at the exact PR head. Compile, device trees, host tests, KUnit, package and final result pass. QEMU virt boot/module loading passes: 1,894 modules loaded, zero unexpected failures, taint 0. The first boot job stalled fetching/checking out its tools; retrying that job and its dependent checks passed. This is a QEMU check, not a physical Mac login test.

No GPU, package installation, compositor restart or fresh M3 login was performed for this change. This tightens the scanner’s admission decision; it does not qualify the general native-Mesa image/login handoff. That physical check remains pending. No kernel, firmware, boot or CODEOWNERS change.

@greptile-apps

greptile-apps Bot commented Oct 25, 2026 •

Copy link
Copy Markdown

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

In --system-provider mode, tracked Bash += assignments now produce an unknown result, keeping the software fallback instead of admitting system Mesa.

  • System-Mesa checks now catch Bash appends to graphics settings.

chriskearney explicitly describes conservative refusal for tracked appends as intentional. The package build and fresh M3 login checks remain pending, as stated in the PR description. Tests were inspected, not run during this review.

Reviews (1) · Last reviewed commit: "mesa-m3: refuse unresolved Bash append o..." · Reviewed by Greptile

@maralcbr

Copy link
Copy Markdown
Member

@chriskearney could you review this when you get a chance? #232 is stacked on it and adds the other half you listed: the 15-inch Air (J615) in both the hook and mesa-m3-system-check, plus automatic system-Mesa selection. With it, a supported Air stops being forced onto LIBGL_ALWAYS_SOFTWARE=1 when the system Mesa admits the node.

How #232 behaves:

  • It replaces only the software fallback. An active /opt/mesa-m3 session is never overridden, so no migration policy changes.
  • It writes the login attempt record before admitting. If that write fails, the session stays on software, so an unconfirmed compositor sends the next login of that boot to software instead of looping.
  • An explicit t8122-profile or a node with the 25G83 handoff keeps its own gate. File opt-out behaviour is unchanged.

Tests (Arch ARM container, sh and bash): session env 280, system provider 31, board parser 28, user-setup 51, uwsm 7, udev 5, confirm 9. Checksums match 24/24. The review debate with GPT 6 Astra converged after three fixes. No hardware login yet. aurora-m3-gpu-check will still report the new system-mesa state as inactive; that's a follow-up.

@maralcbr maralcbr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chriskearney the fix is right. With --system-provider, a tracked NAME+=VALUE word now comes back as (name, None) (mesa-m3-user-setup:206-212). judge() already records a None value as an unsure finding (:356-358), so a late LIBGL_ALWAYS_SOFTWARE+=1 or LD_LIBRARY_PATH+=... in uwsm env no longer looks clean, and the hook keeps the software fallback. The name in names filter at :542 drops untracked appends, so MY_TOOLS_PATH+= stays clean. The legacy parser is unchanged. I also like that the test runs Bash in POSIX mode, which proves both assignments really take effect.

Not blocking:

  • The scanner still misses an append split across a line continuation. Bash takes it:
    export LIBGL_ALWAYS_SOFTWARE+\
    =1
    check_envfile() splits on physical lines (:527), and the trailing backslash is dropped (:156-160), so neither line matches. That gap was already there for plain NAME= assignments. If you want to close it, join continuation lines before splitting.
  • The scanner now also refuses a few things that don't really append: an echo LIBGL_ALWAYS_SOFTWARE+=1 word, or a += line in environment.d, which doesn't support appends. Both end on the software fallback, which seems the right trade for system admission. I'm calling it out only so it's a conscious choice.

Approving the code. As you said, this is outside the 4.5 rc scope, so I'd land it after the rc cut together with the stacked #232.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants