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;
> }
next prev 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).