[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1448480194.20113.48.camel@perches.com>
Date: Wed, 25 Nov 2015 11:36:34 -0800
From: Joe Perches <joe@...ches.com>
To: Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
davem@...emloft.net
Cc: Shannon Nelson <shannon.nelson@...el.com>, netdev@...r.kernel.org,
nhorman@...hat.com, sassmann@...hat.com, jogreene@...hat.com,
John Ronciak <john.ronciak@...el.com>,
Carolyn Wyborny <carolyn.wyborny@...el.com>
Subject: Re: [net-next v2 04/15] i40e: remove BUG_ON from feature string
building
On Wed, 2015-11-25 at 10:35 -0800, Jeff Kirsher wrote:
> On Wed, 2015-11-25 at 21:26 +0300, Sergei Shtylyov wrote:
> > On 11/25/2015 09:21 PM, Jeff Kirsher wrote:
> >
> > > From: Shannon Nelson <shannon.nelson@...el.com>
> > >
> > > There's really no reason to kill the kernel thread just because of a
> > > little info string. This reworks the code to use snprintf's limiting to
> > > assure that the string is never too long, and WARN_ON to still put out
> > > a warning that we might want to look at the feature list length.
> > >
> > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
[]
> > > if (pf->flags & I40E_FLAG_VEB_MODE_ENABLED)
> > > - buf += sprintf(buf, "VEB ");
> > > + i += snprintf(&buf[i], REMAIN(i), "VEPA ");
> >
> > Not "VEB "?
>
> Nice catch Sergei, I will wait a till this afternoon to respin the
> patch series, just in case there are other changes needed that our
> validation did not catch. :-)
trivia:
If you redo these, it'd be nicer not to use " " after each
fixed string, but use " " before each fixed string.
The final output string would be 1 byte shorter overall and
not have an excess " " before the newline.
The declaration of i doesn't need initialization to 0:
i = snprintf(buf, INFO_STRING_LEN, "Features: PF-id[%d]", ...
would work.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists