From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH] igb_uio: fix mmap failure
Date: Fri, 1 Jul 2016 15:39:58 +0100 [thread overview]
Message-ID: <577680BE.60408@intel.com> (raw)
In-Reply-To: <4689144.y76TPTqy0y@xps13>
On 7/1/2016 1:47 PM, Thomas Monjalon wrote:
> Thank you Ferruh for taking care of igb_uio.
>
> 2016-07-01 12:35, Ferruh Yigit:
>> With kernels enabled CONFIG_IO_STRICT_DEVMEM option mmap the iomem area
>> to userspace fails:
>
> Maybe some words are missing.
> Please check punctuation of the whole commit message to make it easier
> to understand.
I will re-word.
>
>> EAL: pci_map_resource():
>> cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
>> Invalid argument (0xffffffffffffffff)
>>
>> As a workaround igb_uio can stop reserving PCI memory resources, from
>> kernel point of view io-memory region looks like idle and mmap works
>> again.
>>
>> With this update device io-memory range is not protected against any
>> other kernel driver claim ownership on those resources, which shouldn't
>> be a problem for dpdk usage module.
>
> Why it should not be a problem?
request_mem_region() is a way for driver informing the rest of the
kernel that memory region is used.
And with CONFIG_IO_STRICT_DEVMEM=y, userspace also prevented to touch
that ares.
But for igb_uio, we explicitly want userspace to access that memory range.
> Please could you give an example of what could happen?
Technically device lost a protection of its memory region against any
other driver, but I am not sure if this is real threat in practical life.
Also this is same in uio_pci_generic, it doesn't reserve the memory.
>
> This patch fixes a problem with recent kernels (not mentioned above)
> which offer the uio_pci_generic alternative.
Will give kernel version information.
> That's why I think we should fix it only if there is absolutely no
> regression for older kernels.
>
Totally agreed, that is why I expressed my concern, let this patch hang
around a little.
next prev parent reply other threads:[~2016-07-01 14:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 10:21 [dpdk-dev] Issue with igb_uio in Fedora 24 Mcnamara, John
2016-07-01 10:53 ` Ferruh Yigit
2016-07-01 11:35 ` [dpdk-dev] [PATCH] igb_uio: fix mmap failure Ferruh Yigit
2016-07-01 12:47 ` Thomas Monjalon
2016-07-01 14:39 ` Ferruh Yigit [this message]
2016-07-01 14:54 ` Thomas Monjalon
2016-07-01 15:07 ` [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3 Ferruh Yigit
2016-07-01 15:52 ` De Lara Guarch, Pablo
2016-07-01 15:54 ` Ferruh Yigit
2016-07-01 15:59 ` [dpdk-dev] [PATCH v3] igb_uio: fix possible mmap failure for Linux >= v4.5 Ferruh Yigit
2016-07-05 15:00 ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2016-07-10 13:58 ` Thomas Monjalon
2016-07-02 0:12 ` [dpdk-dev] Issue with igb_uio in Fedora 24 De Lara Guarch, Pablo
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=577680BE.60408@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.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 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).