Time for a code audit?

Dan Carpenter dan.carpenter at oracle.com
Tue Feb 23 20:26:00 UTC 2016


On Tue, Feb 23, 2016 at 05:45:55PM +0000, Kershner, David A wrote:
> 
> 
> > -----Original Message-----
> > From: Dan Carpenter [mailto:dan.carpenter at oracle.com]
> > Sent: Friday, February 12, 2016 5:02 PM
> > To: Romer, Benjamin M <Benjamin.Romer at unisys.com>
> > Cc: gregkh at linuxfoundation.org; driverdev-devel at linuxdriverproject.org;
> > Sell, Timothy C <Timothy.Sell at unisys.com>; *S-Par-Maintainer
> > <SParMaintainer at unisys.com>
> > Subject: Re: Time for a code audit?
> > 
> > I looked at the Smatch warnings, plus some bonus stuff I'm still working
> > on.
> > 
> > drivers/staging/unisys/include/iochannel.h:592 add_physinfo_entries()
> > warn: inconsistent indenting
> > drivers/staging/unisys/include/iochannel.h:596 add_physinfo_entries()
> > warn: inconsistent indenting
> > drivers/staging/unisys/include/iochannel.h:600 add_physinfo_entries()
> > warn: XXX should 'inp_pfn + i' be a 64 bit type?
> > 
> > This is because the left side is u64 but we wrap at u32.
> > 
> 
> Dan, thanks for the find. Though I'm curious what options are you using when you run smatch to produce the "warn: XXX should 'inp_pfn +I' be a 64 bit type" message? When I run smatch locally I don't see that message but I see the other two and it is definitely a problem in the codebase that I'm looking at. 
> 

These are things I'm still working on and haven't published yet.  It
feels like it should be a warning though.  I'm not certain the heuristic
to use here.  Sometimes people declare things as u64 when they don't
care.  Also Smatch tries to be clever about if the integer overflow is
actually possible but sometimes it still gets false positives.

regards,
dan carpenter



More information about the devel mailing list