Doing the Two-Step

Sometimes developer conflicts are navigated with grace and poise. For example, Bart Van Assche recently invited public comment on something he'd been working on. Specifically, he pointed out that the Clang C compiler was capable of various compile-time tests – including multithreading safety tests – that could potentially identify bugs in source code. To demonstrate this, he posted a patch containing fixes for almost 900 files in the Linux kernel repository. His main question to the kernel developers was, should Clang's compile-time thread safety checks be enabled by default for the Linux kernel?

Threads and thread safety are pretty insane topics, very easy to get wrong, and very difficult to debug. Threading simply means that there are a bunch of programs all running at the same time (e.g., your web browser, your file editor, your video player, and of course, a giant build of the Linux kernel sucking up resources and making your movie skip frames). Modern operating systems run these threads "simultaneously" by switching between them so quickly that you never notice only one of them is ever actually running at a given moment. But any time a thread requests a bit of memory or some disk space or any other resource on the system, it needs to make sure that it and it alone has access to that resource, even though a thousand other threads may make a thousand similar requests before that one thread can finish using that resource. To solve this, there are many different types of "locks" including mutexes, spinlocks, and others, whose job is to prevent other threads from using a resource for the duration of time it's been claimed. Imagine trying to write kernel features; never forgetting to lock the resources you need at the times you need them, in the ways they need to be locked; and then freeing them up again afterwards. These Clang tests are a lifeline to help you get all that insanity right.

However, using Clang tests wouldn't be as easy as flipping a switch. The kernel sources themselves would need to be modified – not necessarily in terms of the code itself, but the code would need to be "annotated" to let Clang know when and how to do its checks. Annotation is fun! It's essentially a code comment that gives the compiler hints as to how to proceed. A lot of languages support it nowadays, but annotation in some form or other goes back to the early days of computers. So, suggesting using it in Linux is nothing new, although Bart's specific suggestion would involve adopting Clang's specific annotations wholesale throughout the source tree.

[...]