[dpdk-dev] [PATCH 0/5] clean up snprintf use for string copying

Stephen Hemminger stephen at networkplumber.org
Wed Apr 3 17:27:14 CEST 2019


On Wed, 3 Apr 2019 14:57:49 +0000
"Wiles, Keith" <keith.wiles at intel.com> wrote:

> > On Apr 3, 2019, at 9:45 AM, Bruce Richardson <bruce.richardson at intel.com> wrote:
> > 
> > There are quite a few instances remaining in DPDK where snprintf is being
> > used for string copying. These were not being picked up by our existing
> > coccinelle script, but that can be fixed by editing the script and running
> > it against our code. In the process a bug was found and fixed in the
> > bonding pmd, where we were incorrectly specifiying the buffer length
> > parameter to snprintf.
> > 
> > The actual replacement was done in two phases - first replacing all
> > instances where only the snprintf line in question needed changing, then
> > fixing the other instances where we also needed to add in the header
> > include. [Using two stages allowed the header addition to be automated too,
> > since we had a list of files where every one needed the header inclusion]
> > 
> > 
> > Bruce Richardson (5):
> >  net/bonding: fix buffer length when printing strings
> >  devtools/cocci: make strlcpy replacement smarter
> >  devtools/cocci: create safer version of strlcpy script
> >  replace snprintf with strlcpy without adding extra include
> >  replace snprintf with strlcpy
> >   
> 
> Should we not be testing the return values from strlcpy and snprintf, which means we need to create a macro or inline function. We could use a macro and only enable with DEBUG support if we think performance or code size if a problem.
> 
> I am surprised none of the tools are catching these types of problems.
> 
> Not to make Bruce do that change for this patch, but we need to look at it for a later patch IMO.
> 
> Regards,
> Keith
> 

In a lot of cases the error checking should be earlier in the input path.
Detecting overflow late in making a string is unhelpful.  But rejecting
input where the name is too long to start with is safer and better.

It is one of those cases where static checkers tell you there is a
problem but the right solution is farther back in the code, not just
right where the error is reported.



More information about the dev mailing list