All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ernest Zed <kreuzerkrieg at gmail.com>
To: spdk@lists.01.org
Subject: [SPDK] bug in dpdk/lib/librte_eal/linuxapp/eal/eal_memory.c ?
Date: Wed, 07 Mar 2018 15:01:03 +0200	[thread overview]
Message-ID: <CAHK_hpLJrqTbDCat+mhydJvzCPaUTaa-12ZUXHLkhevK31fLRg@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

Hi All,
I've encountered a strange behavior in spdk_mem_register. My code was
running fine in my app until this morning when I transferred it to `clone`d
process, the spdk_mem_register started to fail
in vtophys_get_paddr_pagemap. Maybe it is some `clone` side effect I'm not
aware of (have to admit my Linux knowledge is very limited) but the failure
was a result of rte_mem_virt2phy reading the /proc/self/pagemap file.
The vtophys_get_paddr_pagemap
has a code which checks if the address returned from rte_mem_virt2phy is
zero, then it touches the address just to create physical backing page,
however the rte_mem_virt2phy never return zero so the vtophys_get_paddr_pagemap
never touches the page.
the code in rte_mem_virt2phy as following:
if ((page & 0x7fffffffffffffULL) == 0) <<== Here, my page is 0, should I
touch it to get backing physical page?
return RTE_BAD_IOVA;
when, I guess, it should be something like
if ((page & 0x7fffffffffffffULL) == 0) {
if (page == 0) {
return 0; <<== Return 0, and give vtophys_get_paddr_pagemap a chance to
touch and try to translate it again
} else {
return RTE_BAD_IOVA;
}
}

at least it solved the problem with registering memory using spdk_mem_register.
So far, the code runs as expected.

Sincerely,
Ernest

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 8299 bytes --]

                 reply	other threads:[~2018-03-07 13:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAHK_hpLJrqTbDCat+mhydJvzCPaUTaa-12ZUXHLkhevK31fLRg@mail.gmail.com \
    --to=spdk@lists.01.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 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.