http://lkml.org/lkml/2009/7/25/58
| Date |
Sat, 25 Jul 2009 15:21:54 +0300 (EAT) |
| From |
Dan Carpenter <> |
| Subject |
smatch and tun.c |
Jonathan Corbet from lwn.net suggested that I write a smatch
(http://repo.or.cz/w/smatch.git) script to prevent the tun.c type bugs
from happening again.
I wrote two scripts. One just looks for bugs where a variable is
dereferenced while initializing a local variable and checked for NULL like
this:
int x = foo->bar;
BUG_ON(!foo);
I have a theory that sometimes peoople are sloppy when they initialize
variables. This script printed 96 warnings. The other script prints
those messages along with every other time a variable is dereferenced and
then checked for NULL. This script printed 685 messages.
Smatch scripts tends to have a lot of false positives. The script that
only printed problems with variable initialization was maybe 40% actual
bugs but the one that checked everything was maybe 15% actual bugs. I
guess my theory is correct.
One thing that causes false positives is that some macros need to
check for NULL pointers. Also smatch doesn't handle loops correctly yet.
Sometimes variables get changed inside another function and that isn't
handled correctly yet.
By bugs, I don't mean security bugs, I mean picky little things. Quite
often places have useless checks for NULL. But still it's worth fixing.
I feel bad for just sending this email instead of proper bug reports and
patches, but the truth is that I'm cycling through Africa on a bycicle. I
sleep in a tent. It took me days to scrape together enough electricity
and internet to send this one email...
I have attached a zip file with the warnings from 2.6.31-rc3 allmodconfig.
Here are the instructions if you want to use a different config.
git clone git://repo.or.cz/smatch.git
cd smatch
make
cd /usr/src/linux
make C=1 CHECK=/path/to/smatch modules bzImage | tee warns.txt
egrep '(warn|error):' warns.txt | egrep '(before|initializer)'
regards,
dan carpenter
[unhandled content-type:application/zip]
|
