Nobody likes it when kernels don’t work and even less so when they are broken on a Friday afternoon. Yet that’s what happened last Friday. This was particularly unsettling because at -rc8, the kernel is expected to be rock solid. An early reboot is particularly unsettling. Fortunately, the issue was at least bisected to a commit in the x86 tree. The bad commit changed code for an AMD specific feature but oddly the reboot was seen on non-AMD processors too.

It’s easy to take debug logs for granted when you can get them. The kernel nominally has the ability for an ‘early’ printk but that still requires setup. If your kernel crashes before that, you need to start looking at other debug options (and your life choices). This was unfortunately one of those crashes. Standard x86 laptops don’t have a nice JTAG interface for hardware assisted debugging. Debugging this particular crash was not particularly feasible beyond changing code and seeing if it booted.

I ended up submitting the bisection to the upstream developers. Nobody could immediately see anything wrong with the commit, and few people could reproduce the problem. Ingo Molnar suggested a bunch of reasons why very early boot code tends to break. One of his suggestions was to do a diff between good and bad object files to check the relocations. Interestingly, this showed a new call to ` __stack_chk_fail. When kernel (or any code) is compiled with -fstack-protector, the compiler adds code to verify the stack canary. If the stack canary is overwritten, the code branches to __stack_chk_fail. On x86, checking the stack canary is handled via per-cpu functions. These also need to be set up so using them in very early code is not going to work. This explained why the crash happened on a supposedly good commit: the code did some refactoring to put a structure on the stack which was big enough to trigger the stack protector checking. The developers who submitted the code probably weren't testing with the strong stack protector so they would not have caught this. The fix ended up being simple: put __nostackprotector` on the refactored function.

This code came in as part of the ongoing work for Spectre/Meltdown. All of this work has been an important reminder of why the kernel (usually) follows a particular schedule of when new features are accepted. Bugs are always going to happen but the goal is to find them during the merge window or -rc1, not -rc8. This kernel got a -rc9 release in part due to this bug, hopefully the kernel comes out on schedule this Sunday.