DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tiwei Bie <tiwei.bie@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, maxime.coquelin@redhat.com, zhihong.wang@intel.com,
	bruce.richardson@intel.com, brian.russell@intl.att.com
Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: fix PCI config err handling
Date: Tue, 21 Aug 2018 10:40:30 +0800	[thread overview]
Message-ID: <20180821024030.GA17967@debian> (raw)
In-Reply-To: <1534783535.5764.93.camel@debian.org>

On Mon, Aug 20, 2018 at 05:45:35PM +0100, Luca Boccassi wrote:
> On Mon, 2018-08-20 at 16:18 +0800, Tiwei Bie wrote:
> > On Thu, Aug 16, 2018 at 07:49:43PM +0100, Luca Boccassi wrote:
> > > On Thu, 2018-08-16 at 19:47 +0100, Luca Boccassi wrote:
> > > > From: Brian Russell <brussell@brocade.com>
> > > > 
> > > > In virtio_read_caps and vtpci_msix_detect, rte_pci_read_config
> > > > returns
> > > > the number of bytes read from PCI config or < 0 on error.
> > > > If less than the expected number of bytes are read then log the
> > > > failure and return rather than carrying on with garbage.
> > > > 
> > > > Fixes: 6ba1f63b5ab0 ("virtio: support specification 1.0")
> > > > 
> > > > Signed-off-by: Brian Russell <brussell@brocade.com>
> > > > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > > > ---
> > > > v2: handle additional rte_pci_read_config incomplete reads
> > > > 
> > > >  drivers/net/virtio/virtio_pci.c | 35 +++++++++++++++++++++----
> > > > ----
> > > > ----
> > > >  1 file changed, 22 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/virtio/virtio_pci.c
> > > > b/drivers/net/virtio/virtio_pci.c
> > > > index 6bd22e54a6..ff6f96f361 100644
> > > > --- a/drivers/net/virtio/virtio_pci.c
> > > > +++ b/drivers/net/virtio/virtio_pci.c
> > > 
> > > ...
> > > > @@ -610,9 +613,13 @@ virtio_read_caps(struct rte_pci_device *dev,
> > > > struct virtio_hw *hw)
> > > >  			hw->common_cfg = get_cfg_addr(dev,
> > > > &cap);
> > > >  			break;
> > > >  		case VIRTIO_PCI_CAP_NOTIFY_CFG:
> > > > -			rte_pci_read_config(dev, &hw-
> > > > > notify_off_multiplier,
> > > > 
> > > > -					4, pos + sizeof(cap));
> > > > -			hw->notify_base = get_cfg_addr(dev,
> > > > &cap);
> > > > +			/* Avoid half-reads into hw */
> > > > +			ret = rte_pci_read_config(dev,
> > > > &multiplier,
> > > > 4,
> > > > +					pos + sizeof(cap));
> > > > +			if (ret == 4) {
> > > > +				hw->notify_off_multiplier =
> > > > multiplier;
> > > > +				hw->notify_base =
> > > > get_cfg_addr(dev,
> > > > &cap);
> > > > +			}
> > > >  			break;
> > > >  		case VIRTIO_PCI_CAP_DEVICE_CFG:
> > > >  			hw->dev_cfg = get_cfg_addr(dev, &cap);
> > > 
> > > Tiwei: not 100% sure what's the best way to handle a failure here,
> > > this
> > > will avoid writing to *hw in case of errors. Let me know if this is
> > > OK.
> > 
> > My concern is about reading the virtio capability directly.
> > With this patch, it will give up reading other capabilities
> > when failed to read a full virtio PCI capability structure
> > (the returned bytes are less than the expected bytes) even
> > though when the capability it's reading isn't a virtio vendor
> > specific capability. I'm not quite sure whether it will bring
> > any bad consequence. How about just reading the first two
> > bytes first? Something like this:
> > 
> > https://github.com/freebsd/freebsd/blob/72445a41b3ff/sys/dev/pci/pci.
> > c#L1491-L1497
> 
> I'm not sure, to be honest. That bit didn't give me trouble at all, so
> at this point I'd much rather leave it alone so that the maintainers
> can take care of it how they see fit, if necessary :-)
> 
> I've sent a v3 that removes that individual change.

My concern isn't about the above change (which handled the
errors when reading multiplier). In fact, above change looks
good to me! :-)  I mean the below changes in this patch:

 	while (pos) {
 		ret = rte_pci_read_config(dev, &cap, sizeof(cap), pos);
-		if (ret < 0) {
-			PMD_INIT_LOG(ERR,
-				"failed to read pci cap at pos: %x", pos);
+		if (ret != sizeof(cap)) {
+			PMD_INIT_LOG(DEBUG,
+				     "failed to read pci cap at pos: %x ret %d",
+				     pos, ret);
 			break;
 		}

With this change, it will give up reading other capabilities
when failed to read a full virtio PCI capability structure
(the returned bytes are less than the expected bytes) even
though when the capability it's reading isn't a virtio vendor
specific capability. Maybe it would be better to read the
first two bytes first and check whether it's the capability
we want to parse (i.e. vendor capability and MSIX capability).
Something like this:

https://github.com/freebsd/freebsd/blob/72445a41b3ff/sys/dev/pci/pci.c#L1491-L1497

How do you think?

Thanks

  reply	other threads:[~2018-08-21  2:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 14:30 [dpdk-dev] [PATCH 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-14 14:30 ` [dpdk-dev] [PATCH 2/2] virtio: fix PCI config err handling Luca Boccassi
2018-08-15  3:11   ` Tiwei Bie
2018-08-15  9:50     ` Luca Boccassi
2018-08-16  6:46       ` Tiwei Bie
2018-08-16 10:27         ` Luca Boccassi
2018-08-16 18:47 ` [dpdk-dev] [PATCH 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-16 18:47   ` [dpdk-dev] [PATCH 2/2] virtio: fix PCI config err handling Luca Boccassi
2018-08-16 18:49     ` Luca Boccassi
2018-08-20  8:18       ` Tiwei Bie
2018-08-20 16:45         ` Luca Boccassi
2018-08-21  2:40           ` Tiwei Bie [this message]
2018-08-23 12:52             ` Luca Boccassi
2018-08-24  4:23               ` Tiwei Bie
2018-08-24 17:14                 ` Luca Boccassi
2018-08-20 16:44   ` [dpdk-dev] [PATCH v3 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-20 16:44     ` [dpdk-dev] [PATCH v3 2/2] virtio: fix PCI config err handling Luca Boccassi
2018-08-24 17:14     ` [dpdk-dev] [PATCH v4 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-24 17:14       ` [dpdk-dev] [PATCH v4 2/2] virtio: fix PCI config err handling Luca Boccassi
2018-08-27  5:29         ` Tiwei Bie
2018-08-27 16:52           ` Luca Boccassi
2018-08-28  6:47             ` Tiwei Bie
2018-08-27 16:52       ` [dpdk-dev] [PATCH v5 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-27 16:52         ` [dpdk-dev] [PATCH v5 2/2] virtio: fix PCI config err handling Luca Boccassi
2018-08-28  6:43           ` Tiwei Bie
2018-08-28 10:14             ` Luca Boccassi
2018-08-28 10:12         ` [dpdk-dev] [PATCH v6 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-08-28 10:12           ` [dpdk-dev] [PATCH v6 2/2] net/virtio: fix PCI config err handling Luca Boccassi
2018-10-11 10:27             ` Thomas Monjalon
2018-10-11 10:53               ` Luca Boccassi
2018-10-11 13:01                 ` Tiwei Bie
2018-10-28 23:55                   ` Thomas Monjalon
2018-10-17  9:58           ` [dpdk-dev] [PATCH v6 1/2] bus/pci: harmonize and document rte_pci_read_config return value Luca Boccassi
2018-10-17 10:57             ` Bruce Richardson

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=20180821024030.GA17967@debian \
    --to=tiwei.bie@intel.com \
    --cc=bluca@debian.org \
    --cc=brian.russell@intl.att.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=zhihong.wang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).