[dpdk-dev] Issue with igb_uio in Fedora 24

[dpdk-dev] Issue with igb_uio in Fedora 24

[Mcnamara, John]

Hi,

We have seen an issue when using the igb_uio module in Fedora
24. However, it relates to kernel 4.5+ so it could occur in other
distros/oses.

The issue occurs after binding a nic to igb_uio:

    # ./tools/dpdk_nic_bind.py -b igb_uio 0000:03:00.0
    # ./x86_64-native-linuxapp-gcc/app/test

    EAL: Detected 8 lcore(s)
    EAL: Probing VFIO support...
    PMD: bnxt_rte_pmd_init() called for (null)
    EAL: PCI device 0000:03:00.0 on NUMA socket -1
    EAL:   probe driver: 8086:1533 rte_igb_pmd
    EAL: pci_map_resource():
         cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
         Invalid argument (0xffffffffffffffff)
    EAL: Error - exiting with code: 1
         Cause: Requested device 0000:03:00.0 cannot be used
    
The issue is exposed when the kernel is compiled with option
CONFIG_IO_STRICT_DEVMEM turned on.

This option is new from kernel 4.5 and is on by default in Fedora 24:

    config IO_STRICT_DEVMEM
        bool "Filter I/O access to /dev/mem"
        depends on STRICT_DEVMEM
        ---help---

          If this option is disabled, you allow userspace (root) access
          to all io-memory regardless of whether a driver is actively
          using that range.  Accidental access to this is obviously
          disastrous, but specific access can be used by people
          debugging kernel drivers.

          If this option is switched on, the /dev/mem file only allows
          userspace access to *idle* io-memory ranges (see /proc/iomem)
          This may break traditional users of /dev/mem (dosemu, legacy
          X, etc...)  if the driver using a given range cannot be
          disabled.

          If in doubt, say Y.

This issue doesn't occur with uio_pci_generic.

John

Re: [dpdk-dev] Issue with igb_uio in Fedora 24

[Ferruh Yigit]

On 7/1/2016 11:21 AM, Mcnamara, John wrote:
> Hi,
> 
> We have seen an issue when using the igb_uio module in Fedora
> 24. However, it relates to kernel 4.5+ so it could occur in other
> distros/oses.
> 
> The issue occurs after binding a nic to igb_uio:
> 
>     # ./tools/dpdk_nic_bind.py -b igb_uio 0000:03:00.0
>     # ./x86_64-native-linuxapp-gcc/app/test
> 
>     EAL: Detected 8 lcore(s)
>     EAL: Probing VFIO support...
>     PMD: bnxt_rte_pmd_init() called for (null)
>     EAL: PCI device 0000:03:00.0 on NUMA socket -1
>     EAL:   probe driver: 8086:1533 rte_igb_pmd
>     EAL: pci_map_resource():
>          cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
>          Invalid argument (0xffffffffffffffff)
>     EAL: Error - exiting with code: 1
>          Cause: Requested device 0000:03:00.0 cannot be used
>     
> The issue is exposed when the kernel is compiled with option
> CONFIG_IO_STRICT_DEVMEM turned on.
> 
> This option is new from kernel 4.5 and is on by default in Fedora 24:
> 
>     config IO_STRICT_DEVMEM
>         bool "Filter I/O access to /dev/mem"
>         depends on STRICT_DEVMEM
>         ---help---
> 
>           If this option is disabled, you allow userspace (root) access
>           to all io-memory regardless of whether a driver is actively
>           using that range.  Accidental access to this is obviously
>           disastrous, but specific access can be used by people
>           debugging kernel drivers.
> 
>           If this option is switched on, the /dev/mem file only allows
>           userspace access to *idle* io-memory ranges (see /proc/iomem)
>           This may break traditional users of /dev/mem (dosemu, legacy
>           X, etc...)  if the driver using a given range cannot be
>           disabled.
> 
>           If in doubt, say Y.
> 
> This issue doesn't occur with uio_pci_generic.
> 
> John
> 


Thanks for Pablo figuring out the details, and related config option,
otherwise I was digging same issue without success.

Disabling following code in igb_uio makes it work again:
"pci_request_regions(dev, "igb_uio");"

This call adds device bars as active resources, and with above config
option mmap fails for those addresses.

uio_pci_generic already doesn't have this call, and I can send a patch
to remove this from igb_uio.

BUT, I don't know why that call added at first place and concerned about
any corner case that requires this call.
Anybody out has/knows a reason to keep this call?

Thanks,
ferruh

[dpdk-dev] [PATCH] igb_uio: fix mmap failure

[Ferruh Yigit]

With kernels enabled CONFIG_IO_STRICT_DEVMEM option mmap the iomem area
to userspace fails:

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.

Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 		goto fail_free;
 	}
 
-	/*
-	 * reserve device's PCI memory regions for use by this
-	 * module
-	 */
-	err = pci_request_regions(dev, "igb_uio");
-	if (err != 0) {
-		dev_err(&dev->dev, "Cannot request regions\n");
-		goto fail_disable;
-	}
-
 	/* enable bus mastering on the device */
 	pci_set_master(dev);
 
@@ -441,8 +431,6 @@ fail_release_iomem:
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(udev->pdev);
-	pci_release_regions(dev);
-fail_disable:
 	pci_disable_device(dev);
 fail_free:
 	kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(dev);
-	pci_release_regions(dev);
 	pci_disable_device(dev);
 	pci_set_drvdata(dev, NULL);
 	kfree(udev);
-- 
2.7.4

Re: [dpdk-dev] [PATCH] igb_uio: fix mmap failure

[Thomas Monjalon]

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.

> 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?
Please could you give an example of what could happen?

This patch fixes a problem with recent kernels (not mentioned above)
which offer the uio_pci_generic alternative.
That's why I think we should fix it only if there is absolutely no
regression for older kernels.

Re: [dpdk-dev] [PATCH] igb_uio: fix mmap failure

[Ferruh Yigit]

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.

Re: [dpdk-dev] [PATCH] igb_uio: fix mmap failure

[Thomas Monjalon]

2016-07-01 15:39, Ferruh Yigit:
> On 7/1/2016 1:47 PM, Thomas Monjalon wrote:
> >> 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.

OK thanks for the explanations.
So we are not sure how this memory region can be stolen and
we assume it won't.

> > 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.

It may be valuable to have in 16.07.
I suggest to wait RC3 (mid-July) to integrate it.
We will have a RC4 to test it.

[dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3

[Ferruh Yigit]

mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:

EAL: pci_map_resource():
         cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
         Invalid argument (0xffffffffffffffff)

CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges

As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.

With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this  shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.

Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 		goto fail_free;
 	}
 
-	/*
-	 * reserve device's PCI memory regions for use by this
-	 * module
-	 */
-	err = pci_request_regions(dev, "igb_uio");
-	if (err != 0) {
-		dev_err(&dev->dev, "Cannot request regions\n");
-		goto fail_disable;
-	}
-
 	/* enable bus mastering on the device */
 	pci_set_master(dev);
 
@@ -441,8 +431,6 @@ fail_release_iomem:
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(udev->pdev);
-	pci_release_regions(dev);
-fail_disable:
 	pci_disable_device(dev);
 fail_free:
 	kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(dev);
-	pci_release_regions(dev);
 	pci_disable_device(dev);
 	pci_set_drvdata(dev, NULL);
 	kfree(udev);
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3

[De Lara Guarch, Pablo]

Hi Ferruh,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, July 01, 2016 4:08 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger
> Subject: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux >
> v4.3
> 
> mmap the iomem range of the PCI device fails for kernels that
> enabled CONFIG_IO_STRICT_DEVMEM option:
> 
> EAL: pci_map_resource():
>          cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
>          Invalid argument (0xffffffffffffffff)
> 
> CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
> by default:

This was introduced in kernel 4.5 (change the title as well ;))

> Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
> 
> As a workaround igb_uio can stop reserving PCI memory resources, from
> kernel point of view iomem region looks like idle and mmap works
> again. This matches uio_pci_generic usage.
> 
> With this update device iomem range is not protected against any
> other kernel drivers or userspace access. But this  shouldn't
> be a problem for dpdk usage module since purpose of the igb_uio
> module is to provide userspace access.
> 
> Fixes: af75078fece3 ("first public release")
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3

[Ferruh Yigit]

On 7/1/2016 4:52 PM, De Lara Guarch, Pablo wrote:
> Hi Ferruh,
> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Friday, July 01, 2016 4:08 PM
>> To: dev@dpdk.org
>> Cc: Stephen Hemminger
>> Subject: [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux >
>> v4.3
>>
>> mmap the iomem range of the PCI device fails for kernels that
>> enabled CONFIG_IO_STRICT_DEVMEM option:
>>
>> EAL: pci_map_resource():
>>          cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
>>          Invalid argument (0xffffffffffffffff)
>>
>> CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.4 and not enabled
>> by default:
> 
> This was introduced in kernel 4.5 (change the title as well ;))
"git describe" mislead me but you are right, I will update

$ git describe  90a545e
v4.4-rc5-2-g90a545e

Thanks

> 
>> Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
>>
>> As a workaround igb_uio can stop reserving PCI memory resources, from
>> kernel point of view iomem region looks like idle and mmap works
>> again. This matches uio_pci_generic usage.
>>
>> With this update device iomem range is not protected against any
>> other kernel drivers or userspace access. But this  shouldn't
>> be a problem for dpdk usage module since purpose of the igb_uio
>> module is to provide userspace access.
>>
>> Fixes: af75078fece3 ("first public release")
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 

[dpdk-dev] [PATCH v3] igb_uio: fix possible mmap failure for Linux >= v4.5

[Ferruh Yigit]

mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:

EAL: pci_map_resource():
         cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
         Invalid argument (0xffffffffffffffff)

CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges

As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.

With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this  shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.

Fixes: af75078fece3 ("first public release")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 		goto fail_free;
 	}
 
-	/*
-	 * reserve device's PCI memory regions for use by this
-	 * module
-	 */
-	err = pci_request_regions(dev, "igb_uio");
-	if (err != 0) {
-		dev_err(&dev->dev, "Cannot request regions\n");
-		goto fail_disable;
-	}
-
 	/* enable bus mastering on the device */
 	pci_set_master(dev);
 
@@ -441,8 +431,6 @@ fail_release_iomem:
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(udev->pdev);
-	pci_release_regions(dev);
-fail_disable:
 	pci_disable_device(dev);
 fail_free:
 	kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(dev);
-	pci_release_regions(dev);
 	pci_disable_device(dev);
 	pci_set_drvdata(dev, NULL);
 	kfree(udev);
-- 
2.7.4

Re: [dpdk-dev] Issue with igb_uio in Fedora 24

[De Lara Guarch, Pablo]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, July 01, 2016 11:53 AM
> To: Mcnamara, John; dev@dpdk.org
> Cc: De Lara Guarch, Pablo; Stephen Hemminger
> Subject: Re: [dpdk-dev] Issue with igb_uio in Fedora 24
> 
> On 7/1/2016 11:21 AM, Mcnamara, John wrote:
> > Hi,
> >
> > We have seen an issue when using the igb_uio module in Fedora
> > 24. However, it relates to kernel 4.5+ so it could occur in other
> > distros/oses.
> >
> > The issue occurs after binding a nic to igb_uio:
> >
> >     # ./tools/dpdk_nic_bind.py -b igb_uio 0000:03:00.0
> >     # ./x86_64-native-linuxapp-gcc/app/test
> >
> >     EAL: Detected 8 lcore(s)
> >     EAL: Probing VFIO support...
> >     PMD: bnxt_rte_pmd_init() called for (null)
> >     EAL: PCI device 0000:03:00.0 on NUMA socket -1
> >     EAL:   probe driver: 8086:1533 rte_igb_pmd
> >     EAL: pci_map_resource():
> >          cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
> >          Invalid argument (0xffffffffffffffff)
> >     EAL: Error - exiting with code: 1
> >          Cause: Requested device 0000:03:00.0 cannot be used
> >
> > The issue is exposed when the kernel is compiled with option
> > CONFIG_IO_STRICT_DEVMEM turned on.
> >
> > This option is new from kernel 4.5 and is on by default in Fedora 24:
> >
> >     config IO_STRICT_DEVMEM
> >         bool "Filter I/O access to /dev/mem"
> >         depends on STRICT_DEVMEM
> >         ---help---
> >
> >           If this option is disabled, you allow userspace (root) access
> >           to all io-memory regardless of whether a driver is actively
> >           using that range.  Accidental access to this is obviously
> >           disastrous, but specific access can be used by people
> >           debugging kernel drivers.
> >
> >           If this option is switched on, the /dev/mem file only allows
> >           userspace access to *idle* io-memory ranges (see /proc/iomem)
> >           This may break traditional users of /dev/mem (dosemu, legacy
> >           X, etc...)  if the driver using a given range cannot be
> >           disabled.
> >
> >           If in doubt, say Y.
> >
> > This issue doesn't occur with uio_pci_generic.
> >
> > John
> >
> 
> 
> Thanks for Pablo figuring out the details, and related config option,
> otherwise I was digging same issue without success.
> 
> Disabling following code in igb_uio makes it work again:
> "pci_request_regions(dev, "igb_uio");"
> 
> This call adds device bars as active resources, and with above config
> option mmap fails for those addresses.
> 
> uio_pci_generic already doesn't have this call, and I can send a patch
> to remove this from igb_uio.
> 
> BUT, I don't know why that call added at first place and concerned about
> any corner case that requires this call.
> Anybody out has/knows a reason to keep this call?
> 
> Thanks,
> ferruh
> 
> 

Another workaround to make this work is setting "iomem=relaxed" in the kernel parameters,
to avoid recompiling the kernel with IO_STRICT_DEVMEM disabled.

Thanks,
Pablo

[dpdk-dev] [PATCH v4] igb_uio: fix possible mmap failure for Linux >= v4.5

[Ferruh Yigit]

mmap the iomem range of the PCI device fails for kernels that
enabled CONFIG_IO_STRICT_DEVMEM option:

EAL: pci_map_resource():
         cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
         Invalid argument (0xffffffffffffffff)

CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5 and not enabled
by default:
Linux commit: 90a545e restrict /dev/mem to idle io memory ranges

As a workaround igb_uio can stop reserving PCI memory resources, from
kernel point of view iomem region looks like idle and mmap works
again. This matches uio_pci_generic usage.

With this update device iomem range is not protected against any
other kernel drivers or userspace access. But this  shouldn't
be a problem for dpdk usage module since purpose of the igb_uio
module is to provide userspace access.

Fixes: af75078fece3 ("first public release")

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

---
v4:
*  release notes, resolved issues section updated for this fix
---
 doc/guides/rel_notes/release_16_07.rst    | 14 ++++++++++++++
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 -------------
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst
index 569f562..1ddcdab 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -231,6 +231,20 @@ Examples
 Other
 ~~~~~
 
+* **igb_uio: Fixed possible mmap failure for Linux >= v4.5.**
+
+    mmaping the iomem range of the PCI device fails for kernels that
+    enabled CONFIG_IO_STRICT_DEVMEM option:
+
+    EAL: pci_map_resource():
+             cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
+             Invalid argument (0xffffffffffffffff)
+
+    CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5
+
+    Updated igb_uio to stop reserving PCI memory resources, from
+    kernel point of view iomem region looks like idle and mmap worked
+    again. This matches uio_pci_generic usage.
 
 Known Issues
 ------------
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 45a5720..df41e45 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -342,16 +342,6 @@ igbuio_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
 		goto fail_free;
 	}
 
-	/*
-	 * reserve device's PCI memory regions for use by this
-	 * module
-	 */
-	err = pci_request_regions(dev, "igb_uio");
-	if (err != 0) {
-		dev_err(&dev->dev, "Cannot request regions\n");
-		goto fail_disable;
-	}
-
 	/* enable bus mastering on the device */
 	pci_set_master(dev);
 
@@ -441,8 +431,6 @@ fail_release_iomem:
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(udev->pdev);
-	pci_release_regions(dev);
-fail_disable:
 	pci_disable_device(dev);
 fail_free:
 	kfree(udev);
@@ -460,7 +448,6 @@ igbuio_pci_remove(struct pci_dev *dev)
 	igbuio_pci_release_iomem(&udev->info);
 	if (udev->mode == RTE_INTR_MODE_MSIX)
 		pci_disable_msix(dev);
-	pci_release_regions(dev);
 	pci_disable_device(dev);
 	pci_set_drvdata(dev, NULL);
 	kfree(udev);
-- 
2.7.4

Re: [dpdk-dev] [PATCH v4] igb_uio: fix possible mmap failure for Linux >= v4.5

[Thomas Monjalon]

2016-07-05 16:00, Ferruh Yigit:
> mmap the iomem range of the PCI device fails for kernels that
> enabled CONFIG_IO_STRICT_DEVMEM option:
> 
> EAL: pci_map_resource():
>          cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0):
>          Invalid argument (0xffffffffffffffff)
> 
> CONFIG_IO_STRICT_DEVMEM is introduced in Linux v4.5 and not enabled
> by default:
> Linux commit: 90a545e restrict /dev/mem to idle io memory ranges
> 
> As a workaround igb_uio can stop reserving PCI memory resources, from
> kernel point of view iomem region looks like idle and mmap works
> again. This matches uio_pci_generic usage.
> 
> With this update device iomem range is not protected against any
> other kernel drivers or userspace access. But this  shouldn't
> be a problem for dpdk usage module since purpose of the igb_uio
> module is to provide userspace access.
> 
> Fixes: af75078fece3 ("first public release")
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks

I suggested to apply it in RC3 but we have no comments.
That's why it is part of RC2.