Using smatch to statically analyze the Kernel source code

Thu, Apr 9, 2015 | tags: C programming Kernel Linux

Smatch is a static code analyzer that is currently developed by the kernel-janitors people (but mostly Dan Carpenter according to the git history of the project). As we all know, we are supposed to be using static analysis tools so let’s get to it!

In order to use smatch just git clone, and make the project like in the following commands after having made sure that you have all dependencies installed that are mentioned here.

git clone git://
cd smatch

After building smatch you ideally should let it populate a database of Kernel functions and their arguments. Smatch will use this DB to make its subsequent analysis more accurate. To build the function DB run the shell script located in the smatch repository at smatch_scripts/ from within the source code directory of the kernel you want to analyze. Ideally you want to run smatch on the source code of the linux-next git repo where the code changes for the next release are being integrated. To get the linux-next source code follow the instructions here.

As soon as the function database has been built (which can take one to three hours) you can execute smatch on the Kernel source code. A handy shell script in the smatch repository can be used to do that. Before running this script we have to take two preparatory steps though.

  1. Checkout the newest linux-next tag so that the code you are analyzing has a higher probability of not having already been fixed (the tags are of the form “next-20150327” for March the 27th for example).

  2. Make sure that you have an appropriate .config file in the root of your Kernel source tree. The basics on how this file can be generated is described here. Running make help in the root of the Kernel source tree gives you a more recent overview over the possibilities that exist to generate this file.

Afterwards you can just run the smatch_scripts/ script from within your Kernel source tree to start the static code analysis.

The script will probably run for another two hours or so and will aggregate all warnings smatch produces in a file called warns.txt that is placed into the directory the script was run in.

There will most likely be False Positives in the warns.txt file. These can (and should) be reported to the smatch development mailing list at smatch at Someone will then hopefully figure out how to prevent smatch from reporting these in the future (or, even better, you can do it! :P ).

In my opinion, checking these smatch warnings and providing fixes for them is a much more worthwhile use of time for anyone that is interested in Kernel development than fixing errors. Admittedly, doing so is quite a lot more challenging as well.

For example, the fix for an “unreachable code” warning reported by smatch that I assumed to be a True Positive turned out to be some code that was intentionally put there for potential future use (a.k.a. “defensive coding”). As can be seen by reading the archived email thread of my patch submission something useful came of it in the end anyways.

Additional references:

Don’t hesitate to send comments and/or questions to my public-inbox (view).