4 ms·
The kernels for Gentoo have been all over the place for the past few weeks. I'm running 4.12 at the moment, then the repos updated to 4.14, which wouldn't build
by jaccarmac 9y ago
The kernels for Gentoo have been all over the place for the past few weeks. I'm running 4.12 at the moment, then the repos updated to 4.14, which wouldn't build for me, so I waited a week for genkernel to modernize. When I came back 4.14 had been marked unstable and 4.12 was masked, making 4.9 the latest supported kernel. Seems that whatever is happening is a Big Deal.
- revelation 9y agoThats because Gentoo decided to switch on a new compile flag, then didn't bother to test that the kernel still boots: https://lkml.org/lkml/2017/12/29/449 https://lkml.org/lkml/2017/12/29/449
- amluto 9y agoAnd, for reasons that are entirely unknown, the issue got worse due to one of the PTI patches (written by, and hence tentatively blamed on, yours truly). Presumably it caused some minor change in code generation causing GCC to go nuts. FWIW, the compile flag that Gentoo enabled activates a seriously busted GCC feature, and I'm a bit surprised that Gentoo gets away with it in user code.
- djsumdog 9y agoWhich compile flag is that? (I run Gentoo) Edit: nevermind. It's the -fstack-check flag mentioned in the other comments.
- caf 9y agoIs there anywhere to read up on the bustedness of the stack probing feature? (apart from the obvious incompatibility with trying to do that for kernel code).
- JdeBP 9y agoProbing more than a page size below the current stack pointer is wrong. Probing more than a page size further when one's saved frame area, save area, locals area, and (maximum) calling parameters area do not amount to a page in total is also wrong. For more on the considerations that underpin stack probing, see http://jdebp.eu./FGA/function-perilogues.html#StackProbes http://jdebp.eu./FGA/function-perilogues.html#StackProbes for starters.
- amluto 9y agoAlso, the probe does an unlocked RMW (or 0) instead of a read, which is slower but also wrong in a multithreaded application. The latter is what broke Go.
- caf 9y agoIs that because Go crams the thread stacks closely together and it probed into another thread's stack? Regardless, it seems like RMW (or even just a store) should be fine as long as the stack pointer is adjusted before the probe.
- fasterblade 9y agoThe same compiler (mis-)feature was also the cause of spurious crashes in Go applications (diagnosed about a month ago: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/). Linus's comment is fun: So yes, It's a terminally broken compiler from hell. I assume gentoo has applied some completely broken security patch to their compiler, turning said compiler into complete garbage.
- cookiecaper 9y agoLinus clarified later that he could reproduce on Fedora with the relevant build flag (-fstack-check). His initial assumption that this was caused by an out-of-tree patch specific to Gentoo was incorrect. The patch to "fix" it is explicitly disabling -fstack-check for the kernel build. I believe that will go out in 4.14.11 (it is not in 4.14.10).
- mackal 9y agoThe flag is only enabled by default on hardened gentoo profiles. Non-hardened profiles has it disabled.
- deleted 9y ago[deleted]