C Runtime Overhead (2015)

Re:C Runtime Overhead (2015) by mananaysiempre on Monday January 03, 2022 @02:59PM (#29785772)

Umm, what’s the story with Go on Linux? My understanding is that Linux explicitly supports making syscalls from your own code, it’s just that on platforms where the syscall story is a giant mess (32-bit x86) the prescription is to either use the slow historical interface (INT 80h) or to jump to the vDSO (which will do SYSENTER or SYSCALL or whatever—SYSENTER in particular has the lovely property of not saving the return address, so a common stub is pretty much architecturally required[1]).

If I’m guessing correctly about what you’re referring to, the Go people did something in between, got broken in a Linux kernel release, complained at the kernel people, the kernel got a patch to unbreak them. The story on MacOS or OpenBSD, where the kernel developers will cheerfully tell you to take a hike if you make a syscall yourself, seems much worse to me.

(And yes, I’d say there is a meaningful difference between a couple of instructions in the vDSO and Glibc’s endless wrappers.)

[1]: https://lore.kernel.org/lkml/Pine.LNX.4.44.0212172225410.136...

ETA: Wait, no, I was thinking about the Android breakage[2]. What’s the Go story then?

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...

[ Parent | on HN ]

Re:C Runtime Overhead (2015) by aw1621107 on Monday January 03, 2022 @03:43PM (#29786573)

This gets rather over my head, but my best guess is this bug having to do with the Go runtime underestimating how much stack space vDSO code may need (blog post at [0], fix at [1]).

[0]: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

[1]: https://github.com/golang/go/commit/a158382b1c9c0b95a7d41865...

[ Parent | on HN ]

Re:C Runtime Overhead (2015) by mananaysiempre on Monday January 03, 2022 @05:10PM (#29787671)

> I built 32 kernels, one for each bit of the SHA-1 prefix, which only took 29 minutes.

Oh, that is evil, thank you. I even encountered a link to this article a couple of months ago[1], but wasn’t hooked enough to go and read it.

Though the conclusion sounds somewhat dubious to me: the kernel doesn’t document or control stack usage limits for the vDSO, they happen to blow way up on a system built with obscure (if arguably well-motivated) compiler options, a language runtime that tries to minimize stack usage crashes as a result, and somehow the fault is with the runtime in question for not going via libc (which happens to virtually always run with a large stack and a guard page, thus turning this insidious concurrent memory corruption bug into a mere extremely unlikely crash)?

More like we’re collectively garbage at accounting for our stack usage. To be fair to the kernel developers, I would also never guess, looking at this implementation of clock_gettime() [2], that you could compile it in such a way that it ends up requiring 4K of stack space on pain of memory corruption in concurrent programs only (it originating in the kernel source tree has little to do with the bug, it’s just weirdly-compiled userspace C code executing on a small unguarded stack).

[1] in <https://utcc.utoronto.ca/~cks/space/blog/unix/UnixAPIAndCRun...> via <https://utcc.utoronto.ca/~cks/space/blog/programming/CStackS...>, <https://utcc.utoronto.ca/~cks/space/blog/unix/StackSizeLimit...>, and <https://utcc.utoronto.ca/~cks/space/blog/tech/StackSizeLimit...>.

[2] https://elixir.bootlin.com/linux/latest/C/ident/__cvdso_cloc...

[ Parent | on HN ]

Re:C Runtime Overhead (2015) by mananaysiempre on Monday January 03, 2022 @07:22PM (#29789127)

... And a closer look at one of the Go bugs involved[1] also reveals the kernel build system will now also unconditionally disable the offending stack probing flag[2], as it leaked even into the kernel-space configuration where it would do more straightforward damage.

[1] https://github.com/golang/go/issues/20427#issuecomment-36001...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[ Parent | on HN ]

Re:C Runtime Overhead (2015) by mananaysiempre on Monday January 03, 2022 @08:43PM (#29790055)

By the way, that hashing trick somehow reminds me of edge-notched cards[1]. (Not old enough to have used them, old enough to have seen and played with them.)

[1] https://boingboing.net/2008/06/17/edgenotched-cards-st.html

[ Parent | on HN ]