[dpdk-dev] [RFC] pci: force address of mappings in secondary process

Tan, Jianfeng jianfeng.tan at intel.com
Tue Jul 11 03:56:15 CEST 2017


> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, July 11, 2017 9:13 AM
> To: dev at 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


More information about the dev mailing list