From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
davem@davemloft.net
Cc: Shannon Nelson <shannon.nelson@intel.com>,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, John Ronciak <john.ronciak@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>
Subject: Re: [net-next v2 04/15] i40e: remove BUG_ON from feature string building
Date: Wed, 25 Nov 2015 10:35:35 -0800 [thread overview]
Message-ID: <1448476535.3021.5.camel@intel.com> (raw)
In-Reply-To: <5655FD72.70902@cogentembedded.com>
[-- Attachment #1: Type: text/plain, Size: 4180 bytes --]
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@intel.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.
> >
> > Prompted by a recent Linus diatribe.
> >
> > Change-ID: If52ba5ca1c2344d8bf454a31bbb805eb5d2c5802
> > Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> > Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 34 +++++++++++++++-
> -------------
> > 1 file changed, 18 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index 7715c54..7a4595a 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> [...]
> > @@ -10124,42 +10126,42 @@ static void i40e_print_features(struct
> i40e_pf *pf)
> >
> > buf = string;
> >
> > - buf += sprintf(string, "Features: PF-id[%d] ", hw->pf_id);
> > + i += snprintf(&buf[i], REMAIN(i), "Features: PF-id[%d] ", hw-
> >pf_id);
> > #ifdef CONFIG_PCI_IOV
> > - buf += sprintf(buf, "VFs: %d ", pf->num_req_vfs);
> > + i += snprintf(&buf[i], REMAIN(i), "VFs: %d ", pf-
> >num_req_vfs);
> > #endif
> > - buf += sprintf(buf, "VSIs: %d QP: %d RX: %s ",
> > - pf->hw.func_caps.num_vsis,
> > - pf->vsi[pf->lan_vsi]->num_queue_pairs,
> > - pf->flags & I40E_FLAG_RX_PS_ENABLED ? "PS" :
> "1BUF");
> > + i += snprintf(&buf[i], REMAIN(i), "VSIs: %d QP: %d RX: %s ",
> > + pf->hw.func_caps.num_vsis,
> > + pf->vsi[pf->lan_vsi]->num_queue_pairs,
> > + pf->flags & I40E_FLAG_RX_PS_ENABLED ? "PS" :
> "1BUF");
> >
> > if (pf->flags & I40E_FLAG_RSS_ENABLED)
> > - buf += sprintf(buf, "RSS ");
> > + i += snprintf(&buf[i], REMAIN(i), "RSS ");
> > if (pf->flags & I40E_FLAG_FD_ATR_ENABLED)
> > - buf += sprintf(buf, "FD_ATR ");
> > + i += snprintf(&buf[i], REMAIN(i), "FD_ATR ");
> > if (pf->flags & I40E_FLAG_FD_SB_ENABLED) {
> > - buf += sprintf(buf, "FD_SB ");
> > - buf += sprintf(buf, "NTUPLE ");
> > + i += snprintf(&buf[i], REMAIN(i), "FD_SB ");
> > + i += snprintf(&buf[i], REMAIN(i), "NTUPLE ");
> > }
> > if (pf->flags & I40E_FLAG_DCB_CAPABLE)
> > - buf += sprintf(buf, "DCB ");
> > + i += snprintf(&buf[i], REMAIN(i), "DCB ");
> > #if IS_ENABLED(CONFIG_VXLAN)
> > - buf += sprintf(buf, "VxLAN ");
> > + i += snprintf(&buf[i], REMAIN(i), "VxLAN ");
> > #endif
> > if (pf->flags & I40E_FLAG_PTP)
> > - buf += sprintf(buf, "PTP ");
> > + i += snprintf(&buf[i], REMAIN(i), "PTP ");
> > #ifdef I40E_FCOE
> > if (pf->flags & I40E_FLAG_FCOE_ENABLED)
> > - buf += sprintf(buf, "FCOE ");
> > + i += snprintf(&buf[i], REMAIN(i), "FCOE ");
> > #endif
> > 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. :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-11-25 18:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 18:21 [net-next v2 00/15][pull request] Intel Wired LAN Driver Updates 2015-11-25 Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 01/15] fm10k: use napi_schedule_irqoff() Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 02/15] i40e/i40evf: remove unused tunnel parameter Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 03/15] i40e: Change BUG_ON to WARN_ON in service event complete Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 04/15] i40e: remove BUG_ON from feature string building Jeff Kirsher
2015-11-25 18:26 ` Sergei Shtylyov
2015-11-25 18:35 ` Jeff Kirsher [this message]
2015-11-25 19:36 ` Joe Perches
2015-12-01 20:48 ` Joe Perches
2015-12-02 7:25 ` Jeff Kirsher
2015-12-02 8:38 ` [Intel-wired-lan] [PATCH] i40e: Fix i40e_print_features() VEB mode output Joe Perches
2015-12-02 8:38 ` Joe Perches
2015-12-02 9:56 ` [Intel-wired-lan] " Jeff Kirsher
2015-12-02 9:56 ` Jeff Kirsher
2015-12-02 10:12 ` [Intel-wired-lan] " Joe Perches
2015-12-02 10:12 ` Joe Perches
2015-12-02 20:48 ` [Intel-wired-lan] " David Miller
2015-12-02 20:48 ` David Miller
2015-12-02 21:09 ` [Intel-wired-lan] " Joe Perches
2015-12-02 21:09 ` Joe Perches
2015-12-03 12:13 ` [Intel-wired-lan] " Jeff Kirsher
2015-12-03 12:13 ` Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 05/15] i40e: remove BUG_ON from FCoE setup Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 06/15] i40e: Workaround fix for mss < 256 issue Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 07/15] i40e/i40evf: Add a stat to track how many times we have to do a force WB Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 08/15] i40e: Move the saving of old link info from handle_link_event to link_event Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 09/15] i40e/i40evf: Add comment to #endif Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 10/15] i40e/i40evf: clean up error messages Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 11/15] i40evf: handle many MAC filters correctly Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 12/15] i40e: return the number of enabled queues for ETHTOOL_GRXRINGS Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 13/15] i40e: rework the functions to configure RSS with similar parameters Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 14/15] i40e: create a generic configure rss function Jeff Kirsher
2015-11-25 18:21 ` [net-next v2 15/15] i40e: Bump version to 1.4.2 Jeff Kirsher
2015-11-25 18:58 ` [net-next v2 00/15][pull request] Intel Wired LAN Driver Updates 2015-11-25 David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448476535.3021.5.camel@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=carolyn.wyborny@intel.com \
--cc=davem@davemloft.net \
--cc=jogreene@redhat.com \
--cc=john.ronciak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=shannon.nelson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.