2015-07-16 23:24:22

by Toshi Kani

[permalink] [raw]
Subject: [PATCH RESEND 0/3] mm, x86: Fix ioremap RAM check interfaces

ioremap() checks if a target range is in RAM and fails the request
if true. There are multiple issues in the iormap RAM check interfaces.

1. region_is_ram() always fails with -1.
2. The check calls two functions, region_is_ram() and
walk_system_ram_range(), which are redundant as both walk the
same iomem_resource table.
3. walk_system_ram_range() requires RAM ranges be page-aligned in
the iomem_resource table to work properly. This restriction
has allowed multiple ioremaps to RAM which are page-unaligned.

This patchset solves issue 1 and 2. It does not address issue 3,
but continues to allow the existing ioremaps to work until it is
addressed.

---
resend:
- Rebased to 4.2-rc2 (no change needed). Modified change logs.

---
Toshi Kani (3):
1/3 mm, x86: Fix warning in ioremap RAM check
2/3 mm, x86: Remove region_is_ram() call from ioremap
3/3 mm: Fix bugs in region_is_ram()

---
arch/x86/mm/ioremap.c | 23 ++++++-----------------
kernel/resource.c | 6 +++---
2 files changed, 9 insertions(+), 20 deletions(-)


2015-07-16 23:24:25

by Toshi Kani

[permalink] [raw]
Subject: [PATCH RESEND 1/3] mm, x86: Fix warning in ioremap RAM check

__ioremap_caller() calls __ioremap_check_ram() through
walk_system_ram_range() to check if a target range is in RAM.
__ioremap_check_ram() has WARN_ONCE() in a wrong place where
it warns when the given range is not RAM. This misplaced
warning is not exposed since walk_system_ram_range() only
calls __ioremap_check_ram() for RAM ranges.

Move the WARN_ONCE() to __ioremap_caller(), and update the
message to include the address range.

Signed-off-by: Toshi Kani <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
---
arch/x86/mm/ioremap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index cc5ccc4..fd3df0d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -63,8 +63,6 @@ static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
!PageReserved(pfn_to_page(start_pfn + i)))
return 1;

- WARN_ONCE(1, "ioremap on RAM pfn 0x%lx\n", start_pfn);
-
return 0;
}

@@ -131,8 +129,11 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
pfn = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
+ __ioremap_check_ram) == 1) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
+ phys_addr, last_addr);
return NULL;
+ }
}
/*
* Mappings have to be page-aligned

2015-07-16 23:25:08

by Toshi Kani

[permalink] [raw]
Subject: [PATCH RESEND 2/3] mm, x86: Remove region_is_ram() call from ioremap

__ioremap_caller() calls region_is_ram() to walk through the
iomem_resource table to check if a target range is in RAM, which
was added to improve the lookup performance over page_is_ram()
(commit 906e36c5c717 "x86: use optimized ioresource lookup in
ioremap function"). page_is_ram() was no longer used when this
change was added, though.

__ioremap_caller() then calls walk_system_ram_range(), which had
replaced page_is_ram() to improve the lookup performance (commit
c81c8a1eeede "x86, ioremap: Speed up check for RAM pages").

Since both checks walk through the same iomem_resource table for
the same purpose, there is no need to call the two functions.
Furthermore, region_is_ram() always returns with -1, which makes
walk_system_ram_range() as the only check being used at this point.

Therefore, this patch changes __ioremap_caller() to call
walk_system_ram_range() only.

Note, removing the call to region_is_ram() is also necessary to
fix bugs in region_is_ram(). walk_system_ram_range() requires
RAM ranges be page-aligned in the iomem_resource table to work
properly. This restriction has allowed multiple ioremaps to RAM
(setup_data) which are page-unaligned. Using fixed region_is_ram()
will cause these callers to start failing. After all ioremap
callers to setup_data are converted, __ioremap_caller() may call
region_is_ram() instead to remove this restriction.

Signed-off-by: Toshi Kani <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
---
arch/x86/mm/ioremap.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index fd3df0d..b9d4a33 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -92,7 +92,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
pgprot_t prot;
int retval;
void __iomem *ret_addr;
- int ram_region;

/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -115,26 +114,15 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- /* First check if whole region can be identified as RAM or not */
- ram_region = region_is_ram(phys_addr, size);
- if (ram_region > 0) {
- WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
- (unsigned long int)phys_addr,
- (unsigned long int)last_addr);
- return NULL;
- }
-
- /* If could not be identified(-1), check page by page */
- if (ram_region < 0) {
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1) {
- WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
+ WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
phys_addr, last_addr);
- return NULL;
- }
+ return NULL;
}
+
/*
* Mappings have to be page-aligned
*/

2015-07-16 23:24:38

by Toshi Kani

[permalink] [raw]
Subject: [PATCH RESEND 3/3] mm: Fix bugs in region_is_ram()

region_is_ram() looks up the iomem_resource table to check if
a target range is in RAM. However, it always returns with -1
due to invalid range checks. It always breaks the loop at the
first entry of the table.

Another issue is that it compares p->flags and flags, but it
always fails. The flags is declared as int, which makes it as
a negative value with IORESOURCE_BUSY (0x80000000) set while
p->flags is unsigned long.

Fix the range check and flags so that region_is_ram() works as
advertised.

Signed-off-by: Toshi Kani <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Andrew Morton <[email protected]>
---
kernel/resource.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 90552aa..fed052a 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -504,13 +504,13 @@ int region_is_ram(resource_size_t start, unsigned long size)
{
struct resource *p;
resource_size_t end = start + size - 1;
- int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
const char *name = "System RAM";
int ret = -1;

read_lock(&resource_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
- if (end < p->start)
+ if (p->end < start)
continue;

if (p->start <= start && end <= p->end) {
@@ -521,7 +521,7 @@ int region_is_ram(resource_size_t start, unsigned long size)
ret = 1;
break;
}
- if (p->end < start)
+ if (end < p->start)
break; /* not found */
}
read_unlock(&resource_lock);

2015-07-18 01:23:38

by Dan Williams

[permalink] [raw]
Subject: Re: [PATCH RESEND 0/3] mm, x86: Fix ioremap RAM check interfaces

On Thu, Jul 16, 2015 at 4:23 PM, Toshi Kani <[email protected]> wrote:
> ioremap() checks if a target range is in RAM and fails the request
> if true. There are multiple issues in the iormap RAM check interfaces.
>
> 1. region_is_ram() always fails with -1.
> 2. The check calls two functions, region_is_ram() and
> walk_system_ram_range(), which are redundant as both walk the
> same iomem_resource table.
> 3. walk_system_ram_range() requires RAM ranges be page-aligned in
> the iomem_resource table to work properly. This restriction
> has allowed multiple ioremaps to RAM which are page-unaligned.
>
> This patchset solves issue 1 and 2. It does not address issue 3,
> but continues to allow the existing ioremaps to work until it is
> addressed.
>
> ---
> resend:
> - Rebased to 4.2-rc2 (no change needed). Modified change logs.
>
> ---
> Toshi Kani (3):
> 1/3 mm, x86: Fix warning in ioremap RAM check
> 2/3 mm, x86: Remove region_is_ram() call from ioremap
> 3/3 mm: Fix bugs in region_is_ram()
>

For the series...

Reviewed-by: Dan Williams <[email protected]>

I'm going to base my ioremap + memremap series on top of these fixes.

2015-07-21 14:31:49

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [PATCH RESEND 2/3] mm, x86: Remove region_is_ram() call from ioremap

On Thu, 16 Jul 2015, Toshi Kani wrote:
> Note, removing the call to region_is_ram() is also necessary to
> fix bugs in region_is_ram(). walk_system_ram_range() requires
> RAM ranges be page-aligned in the iomem_resource table to work
> properly. This restriction has allowed multiple ioremaps to RAM
> (setup_data) which are page-unaligned. Using fixed region_is_ram()
> will cause these callers to start failing.

Which callers?

Thanks,

tglx

2015-07-21 15:08:33

by Toshi Kani

[permalink] [raw]
Subject: Re: [PATCH RESEND 2/3] mm, x86: Remove region_is_ram() call from ioremap

On Tue, 2015-07-21 at 16:31 +0200, Thomas Gleixner wrote:
> On Thu, 16 Jul 2015, Toshi Kani wrote:
> > Note, removing the call to region_is_ram() is also necessary to
> > fix bugs in region_is_ram(). walk_system_ram_range() requires
> > RAM ranges be page-aligned in the iomem_resource table to work
> > properly. This restriction has allowed multiple ioremaps to RAM
> > (setup_data) which are page-unaligned. Using fixed region_is_ram()
> > will cause these callers to start failing.
>
> Which callers?

They are the callers I noticed.

- Multiple ioremap calls from arch/x86/kernel/kdebugfs.c.
- Multiple ioremap calls from arch/x86/kernel/ksysfs.c.
- pcibios_add_device()

Thanks,
-Toshi

Subject: [tip:x86/urgent] x86/mm: Move warning from __ioremap_check_ram() to the call site

Commit-ID: 1c9cf9b211030a454a84cbc1cb15b82d9aa49011
Gitweb: http://git.kernel.org/tip/1c9cf9b211030a454a84cbc1cb15b82d9aa49011
Author: Toshi Kani <[email protected]>
AuthorDate: Thu, 16 Jul 2015 17:23:14 -0600
Committer: Thomas Gleixner <[email protected]>
CommitDate: Wed, 22 Jul 2015 17:20:33 +0200

x86/mm: Move warning from __ioremap_check_ram() to the call site

__ioremap_check_ram() has a WARN_ONCE() which is emitted when the
given pfn range is not RAM. The warning is bogus in two aspects:

- it never triggers since walk_system_ram_range() only calls
__ioremap_check_ram() for RAM ranges.

- the warning message is wrong as it says: "ioremap on RAM' after it
established that the pfn range is not RAM.

Move the WARN_ONCE() to __ioremap_caller(), and update the message to
include the address range so we get an actual warning when something
tries to ioremap system RAM.

[ tglx: Massaged changelog ]

Signed-off-by: Toshi Kani <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
---
arch/x86/mm/ioremap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index cc5ccc4..fd3df0d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -63,8 +63,6 @@ static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
!PageReserved(pfn_to_page(start_pfn + i)))
return 1;

- WARN_ONCE(1, "ioremap on RAM pfn 0x%lx\n", start_pfn);
-
return 0;
}

@@ -131,8 +129,11 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
pfn = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
+ __ioremap_check_ram) == 1) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
+ phys_addr, last_addr);
return NULL;
+ }
}
/*
* Mappings have to be page-aligned

Subject: [tip:x86/urgent] x86/mm: Remove region_is_ram() call from ioremap

Commit-ID: 9a58eebe1ace609bedf8c5a65e70a097459f5696
Gitweb: http://git.kernel.org/tip/9a58eebe1ace609bedf8c5a65e70a097459f5696
Author: Toshi Kani <[email protected]>
AuthorDate: Thu, 16 Jul 2015 17:23:15 -0600
Committer: Thomas Gleixner <[email protected]>
CommitDate: Wed, 22 Jul 2015 17:20:34 +0200

x86/mm: Remove region_is_ram() call from ioremap

__ioremap_caller() calls region_is_ram() to walk through the
iomem_resource table to check if a target range is in RAM, which was
added to improve the lookup performance over page_is_ram() (commit
906e36c5c717 "x86: use optimized ioresource lookup in ioremap
function"). page_is_ram() was no longer used when this change was
added, though.

__ioremap_caller() then calls walk_system_ram_range(), which had
replaced page_is_ram() to improve the lookup performance (commit
c81c8a1eeede "x86, ioremap: Speed up check for RAM pages").

Since both checks walk through the same iomem_resource table for
the same purpose, there is no need to call both functions.

Aside of that walk_system_ram_range() is the only useful check at the
moment because region_is_ram() always returns -1 due to an
implementation bug. That bug in region_is_ram() cannot be fixed
without breaking existing ioremap callers, which rely on the subtle
difference of walk_system_ram_range() versus non page aligned ranges.

Once these offending callers are fixed we can use region_is_ram() and
remove walk_system_ram_range().

[ tglx: Massaged changelog ]

Signed-off-by: Toshi Kani <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
---
arch/x86/mm/ioremap.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index fd3df0d..b9d4a33 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -92,7 +92,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
pgprot_t prot;
int retval;
void __iomem *ret_addr;
- int ram_region;

/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -115,26 +114,15 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- /* First check if whole region can be identified as RAM or not */
- ram_region = region_is_ram(phys_addr, size);
- if (ram_region > 0) {
- WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
- (unsigned long int)phys_addr,
- (unsigned long int)last_addr);
- return NULL;
- }
-
- /* If could not be identified(-1), check page by page */
- if (ram_region < 0) {
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1) {
- WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
+ WARN_ONCE(1, "ioremap on RAM at 0x%llx - 0x%llx\n",
phys_addr, last_addr);
- return NULL;
- }
+ return NULL;
}
+
/*
* Mappings have to be page-aligned
*/

Subject: [tip:x86/urgent] mm: Fix bugs in region_is_ram()

Commit-ID: 8c38de992be9aed0b34c4fab8f972c83d3b00dc4
Gitweb: http://git.kernel.org/tip/8c38de992be9aed0b34c4fab8f972c83d3b00dc4
Author: Toshi Kani <[email protected]>
AuthorDate: Thu, 16 Jul 2015 17:23:16 -0600
Committer: Thomas Gleixner <[email protected]>
CommitDate: Wed, 22 Jul 2015 17:20:34 +0200

mm: Fix bugs in region_is_ram()

region_is_ram() looks up the iomem_resource table to check if
a target range is in RAM. However, it always returns with -1
due to invalid range checks. It always breaks the loop at the
first entry of the table.

Another issue is that it compares p->flags and flags, but it always
fails. flags is declared as int, which makes it as a negative value
with IORESOURCE_BUSY (0x80000000) set while p->flags is unsigned long.

Fix the range check and flags so that region_is_ram() works as
advertised.

Signed-off-by: Toshi Kani <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
---
kernel/resource.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 90552aa..fed052a 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -504,13 +504,13 @@ int region_is_ram(resource_size_t start, unsigned long size)
{
struct resource *p;
resource_size_t end = start + size - 1;
- int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
const char *name = "System RAM";
int ret = -1;

read_lock(&resource_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
- if (end < p->start)
+ if (p->end < start)
continue;

if (p->start <= start && end <= p->end) {
@@ -521,7 +521,7 @@ int region_is_ram(resource_size_t start, unsigned long size)
ret = 1;
break;
}
- if (p->end < start)
+ if (end < p->start)
break; /* not found */
}
read_unlock(&resource_lock);

2015-07-22 15:38:06

by Toshi Kani

[permalink] [raw]
Subject: Re: [tip:x86/urgent] x86/mm: Move warning from __ioremap_check_ram() to the call site

Thomas,

Dan took this series and updated patch 1/3 (and 2/3 as it contains the
change from 1/3) to fix build warning on i386. Can you please replace
patch 1/3 and 2/3 with the following version?

https://lkml.org/lkml/2015/7/19/365 (Patch 1/3)
https://lkml.org/lkml/2015/7/19/366 (Patch 2/3)
https://lkml.org/lkml/2015/7/19/367 (Patch 3/3)

Thanks,
-Toshi


On Wed, 2015-07-22 at 08:25 -0700, tip-bot for Toshi Kani wrote:
> Commit-ID: 1c9cf9b211030a454a84cbc1cb15b82d9aa49011
> Gitweb:
> http://git.kernel.org/tip/1c9cf9b211030a454a84cbc1cb15b82d9aa49011
> Author: Toshi Kani <[email protected]>
> AuthorDate: Thu, 16 Jul 2015 17:23:14 -0600
> Committer: Thomas Gleixner <[email protected]>
> CommitDate: Wed, 22 Jul 2015 17:20:33 +0200
>
> x86/mm: Move warning from __ioremap_check_ram() to the call site
>
> __ioremap_check_ram() has a WARN_ONCE() which is emitted when the
> given pfn range is not RAM. The warning is bogus in two aspects:
>
> - it never triggers since walk_system_ram_range() only calls
> __ioremap_check_ram() for RAM ranges.
>
> - the warning message is wrong as it says: "ioremap on RAM' after it
> established that the pfn range is not RAM.
>
> Move the WARN_ONCE() to __ioremap_caller(), and update the message to
> include the address range so we get an actual warning when something
> tries to ioremap system RAM.
>
> [ tglx: Massaged changelog ]
>
> Signed-off-by: Toshi Kani <[email protected]>
> Reviewed-by: Dan Williams <[email protected]>
> Cc: Roland Dreier <[email protected]>
> Cc: Luis R. Rodriguez <[email protected]>
> Cc: H. Peter Anvin <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: [email protected]
> Link: http://lkml.kernel.org/r/1437088996-28511-2-git-send-email
> [email protected]
> Signed-off-by: Thomas Gleixner <[email protected]>
> ---
> arch/x86/mm/ioremap.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index cc5ccc4..fd3df0d 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -63,8 +63,6 @@ static int __ioremap_check_ram(unsigned long start_pfn,
> unsigned long nr_pages,
> !PageReserved(pfn_to_page(start_pfn + i)))
> return 1;
>
> - WARN_ONCE(1, "ioremap on RAM pfn 0x%lx\n", start_pfn);
> -
> return 0;
> }
>
> @@ -131,8 +129,11 @@ static void __iomem
> *__ioremap_caller(resource_size_t phys_addr,
> pfn = phys_addr >> PAGE_SHIFT;
> last_pfn = last_addr >> PAGE_SHIFT;
> if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
> - __ioremap_check_ram) == 1)
> + __ioremap_check_ram) == 1) {
> + WARN_ONCE(1, "ioremap on RAM at 0x%llx -
> 0x%llx\n",
> + phys_addr, last_addr);
> return NULL;
> + }
> }
> /*
> * Mappings have to be page-aligned

2015-07-22 16:45:25

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [tip:x86/urgent] x86/mm: Move warning from __ioremap_check_ram() to the call site

On Wed, 22 Jul 2015, Toshi Kani wrote:

> Thomas,
>
> Dan took this series and updated patch 1/3 (and 2/3 as it contains the

Groan. Is this stuff subject to random patch collections?

> change from 1/3) to fix build warning on i386. Can you please replace
> patch 1/3 and 2/3 with the following version?
>
> https://lkml.org/lkml/2015/7/19/365 (Patch 1/3)
> https://lkml.org/lkml/2015/7/19/366 (Patch 2/3)
> https://lkml.org/lkml/2015/7/19/367 (Patch 3/3)

That change in 1/3 should have only addressed the new stuff, the other
%pa changes are not related to this commit.

I'll update it. Sigh.

Thanks,

tglx

2015-07-22 16:57:13

by Toshi Kani

[permalink] [raw]
Subject: Re: [tip:x86/urgent] x86/mm: Move warning from __ioremap_check_ram() to the call site

On Wed, 2015-07-22 at 18:44 +0200, Thomas Gleixner wrote:
> On Wed, 22 Jul 2015, Toshi Kani wrote:
>
> > Thomas,
> >
> > Dan took this series and updated patch 1/3 (and 2/3 as it contains the
>
> Groan. Is this stuff subject to random patch collections?

No, but Dan needed this fix for his series.

Dan, please rebase your series to -tip once it becomes available.

> > change from 1/3) to fix build warning on i386. Can you please replace
> > patch 1/3 and 2/3 with the following version?
> >
> > https://lkml.org/lkml/2015/7/19/365  (Patch 1/3)
> > https://lkml.org/lkml/2015/7/19/366  (Patch 2/3)
> > https://lkml.org/lkml/2015/7/19/367  (Patch 3/3)
>
> That change in 1/3 should have only addressed the new stuff, the other
> %pa changes are not related to this commit.
>
> I'll update it. Sigh.

My apology. I should have notified it to you.

Thanks,
-Toshi