Handle read-only /tmp and missing robust mutexes on OpenHarmony - #132827

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

@dotnet-policy-service agree

CI failure classification (run 2)

The latest push fixes the only PR-caused failures: the four MutexTests.NamedMutex_* tests that failed on the Unix legs in the first run. They failed because the shared-memory files path change (/tmp/ -> Path.GetTempPath()) was not yet scoped to TARGET_OHOS: the tests hardcode /tmp/.dotnet/shm/global, while the runtime followed TMPDIR in the Helix environment. The change is now compiled out on every platform except TARGET_OHOS, and the tests mirror the runtime's path derivation, so the runtime and the tests agree on all platforms. All previously failing Unix legs now pass.

Three legs still fail, all unrelated to this PR:

1. windows-x64 / windows-x86 CoreCLR_AllSubsets — CompositeMLDsaCngTests / CompositeMLDsaFactoryTests (126 failures each) fail with CryptographicException: The requested operation is not supported. The CNG provider on those Helix queues does not support Composite ML-DSA. This PR does not touch any crypto code, and the same tests pass on the osx-arm64 NativeAOT leg in this run, confirming this is environment-specific rather than caused by this PR.
2. browser-wasm linux Release LibraryTests_EAT — a single WasmTestOnChrome work item times out (first run: System.IO.Compression.ZipFile.Tests, this run: System.Drawing.Primitives.Tests) — a known browser-automation flake.

Build Analysis and the aggregate runtime check fail as a consequence of the above.

Tracking issue for the overall OpenHarmony (HarmonyOS) porting effort: #132866

This PR is ready for review. It is the first PR of a series adding OpenHarmony (HarmonyOS) support to the runtime (tracking issue: #132866). The changes are guarded by TARGET_OHOS, which no existing build sets, so they are no-ops on all currently supported platforms.

The PR spans three areas, so I'm pinging the respective owners:

• @dotnet/area-system-io / @jeffhandley — SharedMemoryManager.Unix.cs: on TARGET_OHOS, shared-memory files now honor TMPDIR via Path.GetTempPath() (the sandbox mounts /tmp read-only). All other platforms keep the existing /tmp/ behavior; the MutexTests.NamedMutex_* tests mirror the runtime's path derivation.
• @dotnet/area-system-threading / @JulieLeeMSFT / @VSadov — NamedMutex.Unix.cs: fall back to the shared-memory-file implementation on TARGET_OHOS (the sysroot's pthread lacks robust mutexes), plus the matching test update in MutexTests.cs.
• @dotnet/gc / @anicka-net — numasupport.cpp: compile out the NUMA probe syscalls (get_mempolicy/mbind) on TARGET_OHOS; they are blocked by the sandbox's seccomp policy and SIGSYS-crash the process at startup.
• Supporting: OperatingSystem.IsOhos() (internal, mirrors IsHaiku()) and the TARGET_OHOS define in System.Private.CoreLib.Shared.projitems.

CI status: the only PR-caused failures (four MutexTests.NamedMutex_* tests on the Unix legs) were fixed in the latest push and all Unix legs now pass. The remaining failures — CompositeMLDsa* on two Windows legs and a browser-wasm WasmTestOnChrome time-out — are unrelated to this PR (details in my earlier comment).

Happy to split the GC change into a separate PR if preferred.

Is HarmonyOS only used in tablet/mobile/IOT scenarios or is it used in desktop scenarios as well? Would it be reasonable to use the in-process-only NamedMutex implementation like we do for Android, iOS, and MacCatalyst?

Good questions. HarmonyOS NEXT is used across phones, tablets, and IoT devices, but it also targets desktop-class devices (HarmonyOS NEXT for PC), so cross-process synchronization is a real scenario for applications ported from Linux/Windows. Now，I am porting the dotnet runtime to harmonyos by AI in HarmonyOS PC.
A few considerations on the in-process-only option:

• The shared-memory-file fallback (same path as OpenBSD/Haiku) preserves cross-process named-mutex semantics. An in-process-only implementation would silently reduce named mutexes to process-local on HarmonyOS, which would change behavior for ported desktop apps without any signal to the caller.
• Shared memory files are not only used by NamedMutex: the wait subsystem (e.g., cross-process named EventWaitHandle) relies on the same SharedFilesPath directory, so the TMPDIR change in SharedMemoryManager.Unix.cs is needed regardless of the NamedMutex approach. (Note that the TMPDIR path is only compiled in under TARGET_OHOS, so existing platforms are unaffected.)

If the maintainers prefer the in-process-only NamedMutex for the initial OHOS milestone, we can switch — it would drop one of the three runtime fixes from this PR, while the TMPDIR change would remain.

There are no named event wait handles on non-Windows, your AI assessment is incorrect there.

Also, it looks like HarmonyOS is shifting to its own kernel instead of Linux. Can we change the RID to be ohos instead of linux-ohos since it's not guaranteed to be Linux based?

Thanks for the feedback — you're right on both points. I've verified in the code that there are no named event wait handles or named semaphores on non-Windows (both throw PlatformNotSupportedException on Unix), so shared memory files are used exclusively by the cross-process NamedMutex path — my earlier statement was incorrect.

On the RID: HarmonyOS PC currently ships with two kernel variants — linux-ohos (Linux kernel) and harmony-ohos (the HarmonyOS native kernel) — across both arm and x86. Since the kernel is not guaranteed to be Linux-based, I agree ohos is the right RID going forward. The property and define names in this PR (TargetsOhos / TARGET_OHOS) are already kernel-agnostic, and the follow-up build-infrastructure PR will use the ohos RID.

On NamedMutex: The primary target for this port right now is HarmonyOS PC — running the .NET runtime on desktop-class devices to develop .NET applications for Harmony devices. The current design references Apple's macOS implementation: cross-process named mutexes backed by shared memory files, with the shared directory resolved via TMPDIR because the HarmonyOS sandbox mounts /tmp read-only.

Inspired by this discussion, I've refined the design to also cover non-PC devices that don't need cross-process mutexes: the cross-process path becomes selectable per device class through the existing build configuration (FeatureCrossProcessMutex, the same mechanism that gates iOS/Android). PC builds keep the macOS-style shared-memory-file implementation; builds for non-PC devices simply leave the feature disabled, which automatically excludes the shared-memory files code from compilation and falls back to the in-process named-mutex implementation — exactly like iOS and Android.

Concretely, this is a one-line condition on FeatureCrossProcessMutex in System.Private.CoreLib.Shared.projitems plus a TargetsOhosMobile property set by the build for non-PC targets (e.g. the ohos-mobile-arm64 RID). No other mobile behaviors (such as AssemblyDependencyResolver or PosixSignalRegistration) are affected, and the current PR itself stays unchanged — it provides the PC path.

Does this design sound reasonable? If you'd prefer not to have this variability, I can fall back to disabling the cross-process path for OHOS entirely (the simpler, iOS-aligned approach).

You can ask your AI model to analyze the merge commits of OpenBSD PRs, which we have recently ported: https://github.com/dotnet/runtime/pulls?q=is:pr+label:os-openbsd. Then ask it to start porting the code. Once you have full set of changes in a branch; cross building, infra, coreclr, tools, r2r, aot, libraries, corehost, installer, you can create smaller branches with substantial work then upstream them sequentially like infra+coreclr changes in one PR, each library changes in a separate PR, dotnet/arcade upstreamed there and so on.

This way reviewer can make sense of what's going on, we can test what's being upstreamed etc. which is better than starting off of a random point and using undefined stuff like TARGET_OHOS.

@am11

Thanks for the guidance — the OpenBSD port's pattern (e.g. #130761 CI leg, #129906 NativeAOT stubs, #130478 exepath — small, focused PRs) is exactly the model we intend to follow, and it's how this effort is already structured.

The full OHOS integration is staged on a dedicated branch (43 files in the runtime repo + 19 in the SDK repo) and split into sequential upstream PRs, tracked in #132866:

1. This PR — runtime sandbox fixes, a no-op on all existing platforms
2. Build infrastructure PR — -os linux-ohos + NDK toolchain, which defines TargetsOhos / TARGET_OHOS (16 files)
3. Sysroot compile fixes + NativeAOT support (13 files)
4. Remaining changes split per library into separate PRs
5. SDK repo changes (RID graph, codesign) upstreamed separately

On the RID: both OpenHarmony and HarmonyOS currently ship Linux-based (linux-ohos) in their latest releases, and my porting branch (feature/ohos-cross-runtime) still uses linux-ohos. That said, I agree with jkoritzinsky that ohos is the more future-proof definition, and I'm waiting for his final decision. If the RID remains linux-ohos, I'll split and submit the complete PR series right after his decision; if it moves to ohos, I'll need some time to switch both the runtime and SDK repos from linux-ohos to ohos and re-verify end-to-end before submitting the complete series.

On "undefined TARGET_OHOS": it is a compile-time no-op until the infrastructure PR lands — we verified the builds are byte-identical on every existing platform and CI is green — and the ordering is deliberate so each PR stays independently reviewable; the infra PR simply flips the switch. That said, if you'd prefer the infra PR to land first so TARGET_OHOS is defined from the start, we can reorder the series.

The point was this is not the good first PR from "ordering" perspective of new platform port. The first PR for a new platform is normally expected to be touching places like eng/ dir or max eng/+src/coreclr dirs and precisely updating eng/native/, eng/common/{native,cross}/, eng/Subsets.props, code changes in coreclr etc. not some random project under src/libraries when nothing about this platform is defined in the repo.

The full OHOS integration is staged on a dedicated branch (43 files in the runtime repo + 19 in the SDK repo) and split into sequential upstream PRs, tracked in #132866:

You could use stacked PR approach for this port, it would help the future platforms port: https://docs.github.com/pull-requests/how-tos/stacked-pull-requests When we started OpenBSD port few months ago, stacked PR concept didn't exist. I'd have definitely opted for it.

@am11

Thanks — I've applied all three renames in the latest push (cc9ccb3): TARGET_OHOS -> TARGET_OPENHARMONY, IsOhos() -> IsOpenHarmony(), and TargetsOhos -> TargetOpenHarmony (MSBuild). The follow-up infrastructure now uses the same naming, and the PR description is updated.

On the ordering: agreed. The build infrastructure PR is now up as #132953 (-os linux-ohos, NDK toolchain, defines TargetOpenHarmony / TARGET_OPENHARMONY) — it is the first PR of the series. This PR (#132827, sandbox fixes) is the second, and it depends on #132953 so that TARGET_OPENHARMONY is defined from the start; I'll rebase it onto the updated main once #132953 merges. The remaining series (sysroot compile fixes + NativeAOT support, RID/packs, per-library changes, SDK repo) follows the same split, tracked in #132866.

Since this is a fork-based contribution, the PRs are submitted sequentially (each against main) rather than as GitHub stacked PRs, with the dependency noted in each description; after each PR merges I rebase the next one on the updated main so each diff stays small.

Small fork-side housekeeping note — no action needed, and nothing here changes this PR:

• The legacy libnuma-shim.so LD_PRELOAD workaround has been retired from the fork (sdk-ohos a6f732da1e): with this PR's compile-time elimination of the get_mempolicy/mbind paths on OpenHarmony (numasupport.cpp), the shim is no longer needed. The legacy wrapper no longer injects LD_PRELOAD (its sources and the prebuilt .so are gone).
• The fork build pipeline no longer commits its build packs; it now fetches them on demand with pinned sha256 digests (stock crossgen2 + the reference runtime pack). The end-to-end runtime -> aspnetcore -> sdk CI is green after the change (sdk-ohos run 35046715536).

This PR's head is unchanged (6ed2f9ab9a6) and its build legs remain green; the only red check stays the unrelated Monitor Helix Jobs test-infrastructure monitor.

Friendly ping on this one — is there anything else needed before it can merge?

Current state on head 6ed2f9ab9a:

• @akoeplinger's 2026-09-14 suggestion is in: OSPlatformName now reports OPENHARMONY
  and the MutexTests case uses OperatingSystem.IsOSPlatform("openharmony").
• Build/test legs are green; the only failures are the known infra checks
  (Monitor Helix Jobs et al.). The remaining review threads are outdated.
• No code changes since 09-15.

Context: the follow-up runtime-port PRs are prepared. It would help to know whether
these two can land first so the follow-ups are based on a clean tree, or if you'd
prefer a different order — happy to follow your preference.

looks good to me. there is a merge conflict in src/libraries/System.Private.CoreLib/src/System/Threading/NamedMutex.Unix.cs that needs to be handled before this can be merged

Conflict resolved — the branch is now merged with current main and the NamedMutex.Unix.cs conflict is fixed by keeping the arm/arm64 guard from #134541 and adding the OpenHarmony exclusion to the final condition:

        // On Linux arm and arm64, we do not use PThread mutex-backed named mutexes for compatibility with previous .NET versions.
        // On OpenHarmony, the musl sysroot does not provide the robust mutex APIs
        // (pthread_mutexattr_setrobust / pthread_mutex_consistent).
        private static bool UsePThreadMutexes =>
#if (TARGET_ARM || TARGET_ARM64)
            !OperatingSystem.IsLinux() &&
#endif
            !OperatingSystem.IsApplePlatform() && !OperatingSystem.IsFreeBSD() && !OperatingSystem.IsOpenBSD() && !OperatingSystem.IsHaiku() && !OperatingSystem.IsOpenHarmony();

CI is re-running on the new head 2511c989dbb.

Note for context: an on-device build check on OpenHarmony is currently blocked by an unrelated toolchain gap (the local SDK bundle is on the 11.x line while main has retargeted the in-build tools to net12), so this update relies on the CI here.

@akoeplinger @jkotas PTAL.

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

As suggested in the review, I split out the named-mutex part into #135321, which is independent of the shared-memory changes. What remains here is the shared-memory /tmp-TMPDIR handling plus its test updates, so I'll keep this one parked until the in-progress shared-memory design work lands.