patches for DPDK stable branches
 help / color / mirror / Atom feed
From: huangdengdui <huangdengdui@huawei.com>
To: <stable@dpdk.org>
Subject: Re: [PATCH v2 1/2] bus/pci: fix secondary process PCI uio resource map problem
Date: Tue, 30 Jan 2024 15:12:20 +0800	[thread overview]
Message-ID: <5e9732be-61ce-479c-80d6-e1559aee1a01@huawei.com> (raw)
In-Reply-To: <20240129092231.3531217-2-chaoyong.he@corigine.com>


On 2024/1/29 17:22, Chaoyong He wrote:
> From: Zerun Fu <zerun.fu@corigine.com>
> 
> For the primary process, the logic loops all BARs and will skip
> the map of BAR with an invalid physical address (0), also will
> assign 'uio_res->nb_maps' with the real mapped BARs number. But
> for the secondary process, instead of loops all BARs, the logic
> using the 'uio_res->nb_map' as index. If the device uses continuous
> BARs there will be no problem, whereas if it uses discrete BARs,
> it will lead to mapping errors.
> 
> Fix this problem by also loops all BARs and skip the map of BAR
> with an invalid physical address in secondary process.
> 
> Fixes: 9b957f378abf ("pci: merge uio functions for linux and bsd")Hi, Chaoyong
This patch is just a code refactoring, this bug is caused by the following patch:

Fixes: e6cf7bee1c77 ("bus/pci: fix UIO resource access from secondary process")

> Cc: mukawa@igel.co.jp
> Cc: stable@dpdk.org
> 
> Signed-off-by: Zerun Fu <zerun.fu@corigine.com>
> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> Reviewed-by: Long Wu <long.wu@corigine.com>
> Reviewed-by: Peng Zhang <peng.zhang@corigine.com>

test by the igb_uio driver on the ARM.
Tested-by: Dengdui Huang <huangdengdui@huawei.com>

> ---
>  drivers/bus/pci/pci_common_uio.c | 94 ++++++++++++++++++++------------
>  1 file changed, 60 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/bus/pci/pci_common_uio.c b/drivers/bus/pci/pci_common_uio.c
> index 76c661f054..fcd8a49daf 100644
> --- a/drivers/bus/pci/pci_common_uio.c
> +++ b/drivers/bus/pci/pci_common_uio.c
> @@ -23,10 +23,57 @@ static struct rte_tailq_elem rte_uio_tailq = {
>  };
>  EAL_REGISTER_TAILQ(rte_uio_tailq)
>  
> +static int
> +pci_uio_map_secondary_resource_by_index(struct rte_pci_device *dev,
> +		int res_idx, struct mapped_pci_resource *uio_res, int map_idx)
> +{
> +	int fd, i;
> +
> +	if (map_idx >= uio_res->nb_maps)
> +		return -1;
> +
> +	/*
> +	 * open devname, to mmap it
> +	 */
> +	fd = open(uio_res->maps[map_idx].path, O_RDWR);
> +	if (fd < 0) {
> +		RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> +			uio_res->maps[map_idx].path, strerror(errno));
> +		return -1;
> +	}
> +
> +	void *mapaddr = pci_map_resource(uio_res->maps[map_idx].addr,
> +			fd, (off_t)uio_res->maps[map_idx].offset,
> +			(size_t)uio_res->maps[map_idx].size, 0);
> +
> +	/* fd is not needed in secondary process, close it */
> +	close(fd);
> +	if (mapaddr != uio_res->maps[map_idx].addr) {
> +		RTE_LOG(ERR, EAL,
> +			"Cannot mmap device resource file %s to address: %p\n",
> +			uio_res->maps[map_idx].path,
> +			uio_res->maps[map_idx].addr);
> +		if (mapaddr != NULL) {
> +			/* unmap addrs correctly mapped */
> +			for (i = 0; i < map_idx; i++)
> +				pci_unmap_resource(
> +					uio_res->maps[i].addr,
> +					(size_t)uio_res->maps[i].size);
> +			/* unmap addr wrongly mapped */
> +			pci_unmap_resource(mapaddr,
> +				(size_t)uio_res->maps[map_idx].size);
> +		}
When mapaddr == NULL, the addrs correctly mapped should also be unmaped
It may be better to make the following changes

for (i = 0; i < map_idx; i++)
	pci_unmap_resource(uio_res->maps[i].addr, (size_t)uio_res->maps[i].size);
if (mapaddr != NULL)
	pci_unmap_resource(mapaddr, (size_t)uio_res->maps[map_idx].size);


> +		return -1;
> +	}
> +	dev->mem_resource[res_idx].addr = mapaddr;
> +
> +	return 0;
> +}
> +
>  static int
>  pci_uio_map_secondary(struct rte_pci_device *dev)
>  {
> -	int fd, i, j;
> +	int map_idx = 0, res_idx, ret;
>  	struct mapped_pci_resource *uio_res;
>  	struct mapped_pci_res_list *uio_res_list =
>  			RTE_TAILQ_CAST(rte_uio_tailq.head, mapped_pci_res_list);
> @@ -37,41 +84,20 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
>  		if (rte_pci_addr_cmp(&uio_res->pci_addr, &dev->addr))
>  			continue;
>  
> -		for (i = 0; i != uio_res->nb_maps; i++) {
> -			/*
> -			 * open devname, to mmap it
> -			 */
> -			fd = open(uio_res->maps[i].path, O_RDWR);
> -			if (fd < 0) {
> -				RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> -					uio_res->maps[i].path, strerror(errno));
> -				return -1;
> +		/* Map all BARs */
> +		for (res_idx = 0; res_idx != PCI_MAX_RESOURCE; res_idx++) {
> +			 /* skip empty BAR */
> +			if (dev->mem_resource[res_idx].phys_addr == 0)
> +				continue;
> +
> +			ret = pci_uio_map_secondary_resource_by_index(dev, res_idx,
> +					uio_res, map_idx);
> +			if (ret < 0) {
> +				RTE_LOG(ERR, EAL, "Failed to map resources\n");
> +				return ret;
>  			}
>  
> -			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);
> -
> -			/* fd is not needed in secondary process, close it */
> -			close(fd);
> -			if (mapaddr != uio_res->maps[i].addr) {
> -				RTE_LOG(ERR, EAL,
> -					"Cannot mmap device resource file %s to address: %p\n",
> -					uio_res->maps[i].path,
> -					uio_res->maps[i].addr);
> -				if (mapaddr != NULL) {
> -					/* unmap addrs correctly mapped */
> -					for (j = 0; j < i; j++)
> -						pci_unmap_resource(
> -							uio_res->maps[j].addr,
> -							(size_t)uio_res->maps[j].size);
> -					/* unmap addr wrongly mapped */
> -					pci_unmap_resource(mapaddr,
> -						(size_t)uio_res->maps[i].size);
> -				}
> -				return -1;
> -			}
> -			dev->mem_resource[i].addr = mapaddr;
> +			map_idx++;
>  		}
>  		return 0;
>  	}

  parent reply	other threads:[~2024-01-30  7:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24 10:45 [PATCH] " Chaoyong He
     [not found] ` <20240129092231.3531217-1-chaoyong.he@corigine.com>
2024-01-29  9:22   ` [PATCH v2 1/2] " Chaoyong He
2024-01-30  4:00     ` fengchengwen
2024-01-30  7:12     ` huangdengdui [this message]
2024-03-14 10:55     ` Burakov, Anatoly
2024-01-29  9:22   ` [PATCH v2 2/2] bus/pci: fix secondary process save 'FD' problem Chaoyong He
2024-01-30  6:16     ` fengchengwen
2024-03-14 11:01     ` Burakov, Anatoly
     [not found]   ` <20240419032630.1215256-1-chaoyong.he@corigine.com>
2024-04-19  3:26     ` [PATCH v3 1/2] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-06-27 14:00       ` Thomas Monjalon
2024-06-28  1:03         ` Chaoyong He
2024-04-19  3:26     ` [PATCH v3 2/2] bus/pci: fix secondary process save 'FD' problem Chaoyong He
     [not found]     ` <20240628073624.4122899-1-chaoyong.he@corigine.com>
2024-06-28  7:36       ` [PATCH v4 2/3] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-06-28  7:36       ` [PATCH v4 3/3] bus/pci: fix secondary process save 'FD' problem Chaoyong He
2024-07-01 14:14         ` David Marchand
2024-07-02  1:53           ` Chaoyong He
     [not found]       ` <20240702021946.4194102-1-chaoyong.he@corigine.com>
2024-07-02  2:19         ` [PATCH v5 2/3] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-07-02  2:19         ` [PATCH v5 3/3] bus/pci: fix secondary process save 'FD' problem Chaoyong He
     [not found]         ` <20240702074007.1547-1-chaoyong.he@corigine.com>
2024-07-02  7:40           ` [PATCH v6 1/2] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-07-04  9:00             ` Chenbo Xia
2024-07-02  7:40           ` [PATCH v6 2/2] bus/pci: fix secondary process save 'FD' problem Chaoyong He
2024-07-12 17:30             ` David Marchand
2024-07-15  2:24               ` Chenbo Xia

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=5e9732be-61ce-479c-80d6-e1559aee1a01@huawei.com \
    --to=huangdengdui@huawei.com \
    --cc=stable@dpdk.org \
    /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).