Fix fatal sched_setaffinity EPERM failure during PAL initialization on restricted kernels

[Pietrodjaowjao]

Problem

On Android devices running vendor-modified kernel 5.10 with strict SELinux policy, coreclr_initialize silently fails with HRESULT 0x8007054F (ERROR_INTERNAL_ERROR). No diagnostic output is produced, making this extremely difficult to debug. The failure affects a broad category of devices from multiple OEMs shipping Android 13 on kernel 5.10 GKI bases.

Root Cause

During PAL thread initialization in thread.cpp, the runtime calls sched_getaffinity to retrieve the current thread's CPU affinity mask, then immediately calls sched_setaffinity(0, ...) to re-apply it. On these kernels, sched_setaffinity returns EPERM even when passed a mask that was just obtained from sched_getaffinity on the same thread. The existing error handling unconditionally treats any failure as fatal:

st = sched_setaffinity(0, sizeof(cpu_set_t), &cpuSet);
if (st != 0)
{
    ASSERT("sched_setaffinity failed!\n");
    palError = ERROR_INTERNAL_ERROR;
    goto fail;
}

This aborts PAL initialization entirely, returning ERROR_INTERNAL_ERROR to the caller with no further diagnostics.

Fix

Treat EPERM and EACCES from sched_setaffinity as non-fatal, logging a warning and continuing. The thread will run on any available CPU rather than the originally affinitized one, which is acceptable behavior in restricted environments. Any other error code still triggers the existing assert and hard failure.

This is consistent with the snap confinement workarounds already documented and applied in the same file and in gcenv.unix.cpp, which handle similar sched_setaffinity restrictions under snap's default strict confinement. This PR extends that handling to cover additional restricted environments.

Testing

Verified on an Android 13 device with a vendor-modified kernel 5.10, where coreclr_initialize previously failed with 0x8007054F. After this fix, initialization succeeds. Devices running kernel 6.1 (Android 14) are unaffected.

References

• Related snap issue: dotnet core 3.1 self-contained snap #1634

[Pietrodjaowjao]

cc @janvorli

[janvorli]

LGTM, thank you!

[Pietrodjaowjao]

Thanks for merging! Could a .NET 10 backport be considered?

[Pietrodjaowjao]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)

[github-actions]

@Pietrodjaowjao an error occurred while backporting to release/10.0. See the workflow output for details.