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

[springmin]

Summary

HarmonyOS (OpenHarmony) app sandboxes differ from a plain Linux environment in
three ways that break .NET at startup or at runtime. This PR adds the
TARGET_OPENHARMONY platform guard and the three runtime fixes required to run on
HarmonyOS. All changes are no-ops on existing platforms (see "Impact" below).

This is the second PR of the series adding ohos (HarmonyOS) support to
the runtime (tracking issue: #132866). It depends on the build infrastructure
PR #132953, which defines TargetOpenHarmony / TARGET_OPENHARMONY; until that
lands, this PR is a compile-time no-op on every platform. The split keeps the
sandbox fixes reviewable independently of the build infrastructure.

Changes

1. Skip the GC NUMA probe on HarmonyOS (numasupport.cpp)

get_mempolicy/mbind are blocked by the HarmonyOS seccomp policy, so the NUMA
probe SIGSYS-crashes the process at startup. The syscalls are compiled out for
TARGET_OPENHARMONY; the GC falls back to single-node, which is correct for phones.

2. Honor TMPDIR for shared-memory files on HarmonyOS (SharedMemoryManager.Unix.cs)

/tmp is mounted read-only in the HarmonyOS app sandbox, so shared-memory files
(named mutexes, memory-mapped files) must not be placed under a hardcoded
/tmp/. On TARGET_OPENHARMONY the shared-memory files directory is now derived from
Path.GetTempPath(), which honors TMPDIR and matches how the rest of the
runtime resolves the temp directory. All other platforms keep the existing
hardcoded /tmp/ behavior unchanged.

3. Fall back from pthread mutexes for NamedMutex (NamedMutex.Unix.cs)

The HarmonyOS sysroot's pthread lacks robust-mutex support. NamedMutex falls
back to the shared-memory-file implementation (already the path for
OpenBSD/Haiku).

Supporting: OperatingSystem.IsOpenHarmony() + TARGET_OPENHARMONY

• OperatingSystem.IsOpenHarmony() — internal, compile-time TARGET_OPENHARMONY, mirrors
  IsHaiku(). No public API change in this PR.
• System.Private.CoreLib.Shared.projitems — TARGET_OPENHARMONY define constant from
  TargetOpenHarmony (mirroring TargetsAndroid/TARGET_ANDROID).

Tests (MutexTests.cs)

The NamedMutex_* shared-memory tests derive the global shared-memory directory
the same way the runtime does ({SharedFilesPath}/.dotnet/shm/global), mirroring
the platform-conditional selection in change 2, so they stay in sync with the
runtime on every platform.

Impact on existing platforms

None:

• TARGET_OPENHARMONY is only defined when TargetsLinuxOhos == 'true', which no
  existing build sets.
• IsOpenHarmony() returns false on every existing platform.
• numasupport.cpp guards are additive (&& !defined(TARGET_OPENHARMONY)); with
  TARGET_OPENHARMONY undefined the behavior is byte-identical.
• The shared-memory files directory on non-HarmonyOS platforms is unchanged
  (/tmp/); the TMPDIR-honoring path is compiled in only for TARGET_OPENHARMONY.

Validation

• Full clr.native+libs+host+packs -os ohos -arch arm64 --cross cross-build
  succeeds: 0 Warning(s) 0 Error(s).
• libcoreclr.so for ohos-arm64 contains zero references to
  get_mempolicy/mbind (verified via objdump).
• NativeAOT IntermediatesDir path fix verified in the full build.
• CI: the first run failed MutexTests.NamedMutex_* on the Unix legs because the
  shared-memory path change was not yet scoped to TARGET_OPENHARMONY; that is fixed by
  the latest push (the runtime path on non-HarmonyOS platforms is /tmp/ again,
  which the tests target). On the re-run, all previously failing Unix legs pass.
  The remaining failures are unrelated to this PR: CompositeMLDsa* on the
  Windows legs (the Helix Windows queues' CNG provider reports "The requested
  operation is not supported" for Composite ML-DSA; the same tests pass on the
  osx-arm64-NativeAOT leg in this run) and a browser-wasm WasmTestOnChrome
  time-out on the LibraryTests_EAT leg (an infrastructure flake — a different
  test work item failed on each run).

Notes for reviewers

• The build infrastructure (-os ohos, RID graph, NDK toolchain
  plumbing) is intentionally not in this PR — it will follow so each PR is
  independently reviewable. Without it, TARGET_OPENHARMONY is simply never defined.
• HarmonyOS targets are not built in CI yet; the follow-up infra PR will add
  ohos cross legs mirroring linux-bionic.

Note

This PR was authored with AI assistance (Copilot/agent tooling) under the
repository owner's direction.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[springmin]

@dotnet-policy-service agree

[springmin]

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.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[springmin]

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

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

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.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[jkoritzinsky]

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?

[springmin]

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.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[jkoritzinsky]

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?

[springmin]

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).

[am11]

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.

[springmin]

@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.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[am11]

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.

[springmin]

@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.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

CI note: the only failing check is Monitor Helix Jobs (Helix test-infrastructure monitoring — server throttling in the log). All platform build legs succeeded, including the osx-arm64 Libraries_CheckedCoreCLR leg that shows as canceled (it was canceled by the monitor failure, not by its own build). This matches the Helix infra pattern noted earlier on this PR.

Review checklist status (all addressed):

• Named mutex: macOS/BSD model (UsePThreadMutexes excludes OpenHarmony; shared-memory-file fallback) — jkoritzinsky
• TMPDIR-scoped shared-memory path under TARGET_OPENHARMONY — jkoritzinsky
• TargetsOpenHarmony (plural) naming — jkotas
• OpenHarmony terminology throughout; PR title updated
• Upstream main merged (head 0abc710814d) so the PR stays mergeable

Note

This comment was drafted with AI assistance (agent tooling) under the reporter's direction; the merge and CI runs were performed by the reporter.

[springmin]

Two updates for this PR:

RID naming — settled as openharmony. Per @jkoritzinsky's request on #132953 (2026-09-08: "Please change ohos here to openharmony to match what we talked about in the other PR" — #132953 discussion_r3960776248) and @jkotas's guidance (2026-09-04: "I would go with openharmony" — #132827 issuecomment-5533905287). The rename is applied across the forks; #132953 carries the runtime-infra portion and was approved with that head. This PR is compile-macro-level only (TARGET_OPENHARMONY / TargetsOpenHarmony / IsOpenHarmony) — no RID strings in scope, so there is no further change here.

Follow-up commit a250da4de6e — output of a porting-code compliance audit plus a self-review pass:

• SharedMemoryManager.Unix.cs: the "process temp directory" sentence sat above the #if and misdescribed the #else arm (which returns the fixed /tmp path); moved it into the #else branch.
• NamedMutex.Unix.cs: added the missing rationale comment for the OpenHarmony exclusion (the OHOS musl sysroot does not provide pthread_mutexattr_setrobust / pthread_mutex_consistent).
• MutexTests.cs: #if TARGET_OPENHARMONY is never defined outside System.Private.CoreLib, so the OpenHarmony branch was dead code and the test always checked /tmp; it now selects the TMPDIR-based path via RuntimeIdentifier, matching the runtime.

No runtime behavior changes beyond the test path; the reviewed guards are unchanged. Ready for re-review.

[springmin]

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.

[springmin]

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.

[akoeplinger]

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

[springmin]

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.

[dotnet-policy-service]

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