I've had the misfortune of reading the Linux kernel for fun (& profit) since 2014, and a friend asked if I had tips for doing so. Here's what I told him:
— Mark M (@offlinemark) December 7, 2020
Tips for reading the Linux kernel
Leave a reply
Wrote a twitter thread about this:
This was a pretty interesting buggy scenario I found while reading the clang-tidy checks. If you’re writing a function that takes a forwarding reference (what looks like an rvalue reference, but whose type is a template argument), you need to be careful to not call std::move on it. You need to make sure to call std::forward instead. Otherwise, you might accidentally trigger a move on an object passed by a caller! This would be confusing, since their object would be moved from, and they never explicitly called std::move on it.
I got bit by unique_ptr when implementing a linked list today. You need to be careful to manually release() the unique_ptr before resetting or you might accidentally free the entire list. This comes up when doing insertions and stuff like that.
Filmed some screencasts today explaining some interesting behavior with /proc/self/mem — you can use it to write to unwritable memory (including the text of libc!).
Filmed a screencast exploring some neat mmap behavior — read bits are not enforced for memory mappings. This is because the underlying x86 page table entries have a single bit to toggle between “Read” and “Read/Write”.
I landed some code in lldb! Did some tweeting about it here:
I was reading about GCC and noticed this very suspicious warning line about an accidental compatibility break: https://gcc.gnu.org/gcc-8/changes.html

I thought it would be interesting to reproduce this. I reproduced this specific scenario they outline and compiled two translations units, one with GCC 8.1, one with an earlier version (GCC 7) and observed the segfault that happens when two incompatible calling conventions interact with each other.