From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E954AA034F; Wed, 13 May 2020 11:04:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 94A841D418; Wed, 13 May 2020 11:04:36 +0200 (CEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by dpdk.org (Postfix) with ESMTP id 3FF361D417 for ; Wed, 13 May 2020 11:04:35 +0200 (CEST) X-Originating-IP: 86.246.31.132 Received: from u256.net (lfbn-idf2-1-566-132.w86-246.abo.wanadoo.fr [86.246.31.132]) (Authenticated sender: grive@u256.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 61220E000C; Wed, 13 May 2020 09:04:33 +0000 (UTC) Date: Wed, 13 May 2020 11:04:29 +0200 From: =?utf-8?Q?Ga=C3=ABtan?= Rivet To: Stephen Hemminger Cc: Darek Stojaczyk , dev@dpdk.org Message-ID: <20200513090429.szotkif776j7ehqf@u256.net> References: <20200512133057.106374-1-dariusz.stojaczyk@intel.com> <1589307388.25513.0@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1589307388.25513.0@networkplumber.org> Subject: Re: [dpdk-dev] [PATCH] pci: properly parse 32-bit domain numbers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/05/20 11:16 -0700, Stephen Hemminger wrote: > > > On Tue, May 12, 2020 at 3:30 pm, Darek Stojaczyk > wrote: > > The parsing code was bailing on domains greater than UINT16_MAX, > > but domain numbers like that are still valid and present on some > > systems. > > One example is Intel VMD (Volume Management Device), which acts somewhat > > as a software-managed PCI switch and its upstream linux driver assigns > > all downstream devices a PCI domain of 0x10000. > > > > Parsing a BDF like 10000:01:00.0 was failing before. To fix it, increase > > the upper limit of domain number to UINT32_MAX. This matches the size of > > struct rte_pci_addr->domain (uint32). > > > > Signed-off-by: Darek Stojaczyk > > The original code predates the change from macro in commit c742e8d3110b. Fixes: af75078fece3 ("first public release") Cc: stable@dpdk.org Thanks for the fix, Acked-by: Gaetan Rivet > > --- > > lib/librte_pci/rte_pci.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_pci/rte_pci.c b/lib/librte_pci/rte_pci.c > > index d1ab6b414d..ad2cdfebb2 100644 > > --- a/lib/librte_pci/rte_pci.c > > +++ b/lib/librte_pci/rte_pci.c > > @@ -72,9 +72,9 @@ pci_dbdf_parse(const char *input, struct rte_pci_addr > > *dev_addr) > > > > errno = 0; > > val = strtoul(in, &end, 16); > > - if (errno != 0 || end[0] != ':' || val > UINT16_MAX) > > + if (errno != 0 || end[0] != ':' || val > UINT32_MAX) > > return -EINVAL; > > - dev_addr->domain = (uint16_t)val; > > + dev_addr->domain = (uint32_t)val; > > in = end + 1; > > in = get_u8_pciaddr_field(in, &dev_addr->bus, ':'); > > if (in == NULL) > > -- > > 2.17.1 > > > Agree this came up before on Hyper-V as well. It meant fixing libpci. > > Not sure the cast of val is necessary, other than an attempt to silence some > static checker > about implicit type conversion causing loss of precision. > > > > > The cast is useless indeed. Remnants from the original macro. For now best to leave it as-is, make another patch to remove those casts. There are other potential bugs in parsing, -FFFFFFFFFFFF0001 is considered valid (-FFFFFFFF00000001 with this patch) as well as an empty domain. I will send a fix for those. -- Gaëtan