runtime: doAllThreadsSyscall has an unaligned atomic load on 32-bit architectures

[mknyszek]

The 64-bit loads here and here are unaligned on 32-bit architectures (see #599).

I would just fix this, but it's unclear to me what the right fix is. This is right at the top of the m struct, so adding padding is tricky because there could be other 64-bit loads below in the struct that will become unaligned. (I think maybe fastrand? I didn't check, maybe there isn't any.) Simultaneously, making these loads not atomic seems slightly dangerous on weak memory architectures.

This might need a backport to Go 1.18? I think these lines are new in Go 1.18.

CC @prattmic @aclements

[mknyszek]

Oh, I should also mention, these loads are the only atomic accesses of this field.

[prattmic]

procid is actually only 32-bits on Linux (gettid returns uint32), so as a workaround we could cast to *uint32 and use a 32-bit atomic load.

[mknyszek]

We also suspect this isn't actually failing on the builders because cgo needs to be disabled for the test that checks this codepath, and the only nocgo builder for Linux is linux/amd64 (nothing 32-bit).

[prattmic]

cc @golang/release re @mknyszek's note that we have no nocgo coverage outside of amd64.

[dmitshur]

Ack. If it's deemed helpful, adding a 32-bit nocgo builder using any of our virtualized VM-based host types, e.g., linux-386-nocgo, sounds reasonable. I didn't find an existing issue for it (other than a related #22705), so please feel free to file a new one and send a CL for it. I'll prioritize the permissions work to so that you'd also be able to deploy it after the CL lands. Thanks!

[aclements]

Potentially relevant is #50860, since those atomic types would let us fix these alignment issues.

This might need a backport to Go 1.18? I think these lines are new in Go 1.18.

I believe you are right that this is new in 1.18.

[prattmic]

Fixed in https://go.dev/cl/399754.

@gopherbot Please backport to 1.18. This is a regression with no workaround.

[gopherbot]

Backport issue(s) opened: #52305 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/399954 mentions this issue: runtime: align m.procid to 8 bytes on 32-bit systems

[gopherbot]

Change https://go.dev/cl/399955 mentions this issue: [release-branch.go1.18] runtime: align m.procid to 8 bytes on 32-bit systems

[bradfitz]

Even without builder coverage, we could at least have some coverage that all fields in the runtime that are accessed as 64-bit atomics all have correct offsets for a handful of varied build contexts?

[cherrymui]

Does procid really need to be 64-bit? I think it is the tid (thread ID), which is 32-bit on many platforms. Where do we really need 64-bit procid?

[mknyszek]

I asked @prattmic the same thing: it's because on some OSes (any OS that uses pthread_self) represent the thread ID as a uintptr, which in the worst case is 64 bits wide.

Though, we could maybe just make it a uintptr?

[ianlancetaylor]

@mknyszek Is there anything left to do here? This issue is currently in the 1.19 milestone. Thanks.

[mknyszek]

I believe this is now fixed.