Using smatch to statically analyze the Kernel source code
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://repo.or.cz/smatch.git
cd smatch
make
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 build_kernel_data.sh shell script located in the
smatch repository at smatch_scripts/build_kernel_data.sh
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.
-
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).
-
Make sure that you have an appropriate
.configfile in the root of your Kernel source tree. The basics on how this file can be generated is described here. Runningmake helpin 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/test_kernel.sh 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 vger.kernel.org. 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 checkpatch.pl 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: