All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Chaoyong He <chaoyong.he@corigine.com>, <dev@dpdk.org>
Cc: <oss-drivers@corigine.com>, Zerun Fu <zerun.fu@corigine.com>,
	<mukawa@igel.co.jp>, <stable@dpdk.org>,
	Long Wu <long.wu@corigine.com>,
	"Peng Zhang" <peng.zhang@corigine.com>
Subject: Re: [PATCH v2 1/2] bus/pci: fix secondary process PCI uio resource map problem
Date: Thu, 14 Mar 2024 11:55:48 +0100	[thread overview]
Message-ID: <75e1581f-ad24-4ced-bd08-2bbc631fd32e@intel.com> (raw)
In-Reply-To: <20240129092231.3531217-2-chaoyong.he@corigine.com>

On 1/29/2024 10:22 AM, 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")
> 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>
> ---
>   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);
> +		}
> +		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);

Nitpicking, but I feel like this would've been better done from the 
caller, not here. This is how it's done in primary process.

> -				}
> -				return -1;
> -			}
> -			dev->mem_resource[i].addr = mapaddr;
> +			map_idx++;
>   		}
>   		return 0;
>   	}

With fix above,

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly


  parent reply	other threads:[~2024-03-14 10:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24 10:45 [PATCH] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-01-29  9:22 ` [PATCH v2 0/2] fix secondary process PCI UIO resource problem Chaoyong He
2024-01-29  9:22   ` [PATCH v2 1/2] bus/pci: fix secondary process PCI uio resource map problem Chaoyong He
2024-01-30  4:00     ` fengchengwen
2024-03-14 10:55     ` Burakov, Anatoly [this message]
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
2024-03-11  6:42   ` [PATCH v2 0/2] fix secondary process PCI UIO resource problem Chaoyong He
2024-04-19  3:26   ` Chaoyong He
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
2024-06-28  7:36     ` [PATCH v4 0/3] fix secondary process PCI UIO resource problem Chaoyong He
2024-06-28  7:36       ` [PATCH v4 1/3] bus/pci: rename the variable in UIO secondary map logic Chaoyong He
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
2024-07-01 14:12       ` [PATCH v4 0/3] fix secondary process PCI UIO resource problem David Marchand
2024-07-02  2:19       ` [PATCH v5 " Chaoyong He
2024-07-02  2:19         ` [PATCH v5 1/3] bus/pci: rename the variable in UIO secondary map logic Chaoyong He
2024-07-02  2:47           ` Stephen Hemminger
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
2024-07-02  7:40         ` [PATCH v6 0/2] fix secondary process PCI UIO resource problem Chaoyong He
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-15  5:55             ` huangdengdui
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
2024-07-02  9:28           ` [PATCH v6 0/2] fix secondary process PCI UIO resource problem David Marchand
2024-07-23  9:01           ` Thomas Monjalon

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=75e1581f-ad24-4ced-bd08-2bbc631fd32e@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=chaoyong.he@corigine.com \
    --cc=dev@dpdk.org \
    --cc=long.wu@corigine.com \
    --cc=mukawa@igel.co.jp \
    --cc=oss-drivers@corigine.com \
    --cc=peng.zhang@corigine.com \
    --cc=stable@dpdk.org \
    --cc=zerun.fu@corigine.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.