> -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen > Hemminger > Sent: Tuesday, July 11, 2017 9:13 AM > To: dev@dpdk.org > Cc: Stephen Hemminger > Subject: [dpdk-dev] [RFC] pci: force address of mappings in secondary > process > > The PCI memory resources in the secondary process should be in > the exact same location as the primary process. Otherwise > there is a risk of a stray pointer. > > Not sure if this is right, but it looks like a potential > problem. > > --- > lib/librte_eal/common/eal_common_pci_uio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_eal/common/eal_common_pci_uio.c > b/lib/librte_eal/common/eal_common_pci_uio.c > index 367a6816dcb8..2156b1a436c4 100644 > --- a/lib/librte_eal/common/eal_common_pci_uio.c > +++ b/lib/librte_eal/common/eal_common_pci_uio.c > @@ -77,7 +77,7 @@ pci_uio_map_secondary(struct rte_pci_device *dev) > > void *mapaddr = pci_map_resource(uio_res- > >maps[i].addr, > fd, (off_t)uio_res->maps[i].offset, > - (size_t)uio_res->maps[i].size, 0); > + (size_t)uio_res->maps[i].size, > MAP_FIXED); > /* fd is not needed in slave process, close it */ > close(fd); > if (mapaddr != uio_res->maps[i].addr) { > -- > 2.11.0
+1 for this RFC. I also once encounter such problem, and I use the same way to solve it. The addr parameter of mmap() syscall is only a hint instead of a must even the VMA is not occupied yet. Thanks, Jianfeng
