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