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: [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 Issue with igb_uio in Fedora 24 Mcnamara, John
2016-07-01 10:53 ` Ferruh Yigit
2016-07-01 11:35 ` [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 ` [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 ` [PATCH v3] igb_uio: fix possible mmap failure for Linux >= v4.5 Ferruh Yigit
2016-07-05 15:00 ` [PATCH v4] " Ferruh Yigit
2016-07-10 13:58 ` Thomas Monjalon
2016-07-02 0:12 ` 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 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.