ioremap: Delay sanity check until after a successful mapping
PATCH 1/1 ioremap: Delay sanity check until after a successful mapping
While tracking down the reason for an ioremap() failure I was distracted by the WARN_ONCE() in __ioremap_caller(). Can we move the sanity check later in the function until _after_ the mapping has been performed?
rtg
Signature · 1 line
Tim Gardner [email protected]
Quoted 1 line
From
31dec327a254888fcd0b6aa963414b09626d3168Mon Sep 17 00:00:00 2001
From: Tim Gardner <[email protected]>
Date: Thu, 28 Apr 2011 10:07:51 -0600
Subject: [PATCH] ioremap: Delay sanity check until after a successful mapping
Performing a WARN_ONCE() sanity check before the mapping
is successful seems pointless if the caller sends bad values. A case in point is when the BIOS provides erroneous screen_info values causing vesafb_probe() to request an outrageuous size. The WARN_ONCE is then wasted on bogosity. Move the warning to a point where the mapping has been successfully allocated.
http://bugs.launchpad.net/bugs/772042
--- arch/x86/mm/ioremap.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
arch/x86/mm/ioremap.c +7 -7
@@ -91,13 +91,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,return (__force void __iomem *)phys_to_virt (phys_addr);/* -* Check if the request spans more than any BAR in the iomem resource -* tree. -*/ -WARN_ONCE (iomem_map_sanity_check (phys_addr, size), -KERN_INFO "Info: mapping multiple BARs. Your kernel is fine." ); - -/* * Don't allow anybody to remap normal RAM that we're using.. */ last_pfn = last_addr >>PAGE_SHIFT ;
@@ -170,6 +163,13 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, ret_addr = (void __iomem *) (vaddr + offset);mmiotrace_ioremap (unaligned_phys_addr, unaligned_size, ret_addr); +/* +* Check if the request spans more than any BAR in the iomem resource +* tree. +*/ +WARN_ONCE (iomem_map_sanity_check (unaligned_phys_addr, unaligned_size), +KERN_INFO "Info: mapping multiple BARs. Your kernel is fine." ); +return ret_addr; err_free_area:free_vm_area (area);
Signature · 1 line
1.7.0.4
Quoted 6 lines · Tim Gardner
While tracking down the reason for an
ioremap()failure I was distracted
by theWARN_ONCE()in__ioremap_caller(). Can we move the sanity check
later in the function until _after_ the mapping has been performed?
Quoted 29 lines
rtg
Signature · 27 lines
Tim Gardner [email protected] differences between files attachment (0001-ioremap-Delay-sanity-check-until-after-a-successful-.patch) From 31dec327a254888fcd0b6aa963414b09626d3168 Mon Sep 17 00:00:00 2001 From: Tim Gardner <[email protected]> Date: Thu, 28 Apr 2011 10:07:51 -0600 Subject: [PATCH] ioremap: Delay sanity check until after a successful mapping Performing a WARN_ONCE() sanity check before the mapping is successful seems pointless if the caller sends bad values. A case in point is when the BIOS provides erroneous screen_info values causing vesafb_probe() to request an outrageuous size. The WARN_ONCE is then wasted on bogosity. Move the warning to a point where the mapping has been successfully allocated. http://bugs.launchpad.net/bugs/772042
Sounds good to me.
thanks.
Commit-ID: c7a7b814c9dca9ee01b38e63b4a46de87156d3b6 Gitweb: http://git.kernel.org/tip/c7a7b814c9dca9ee01b38e63b4a46de87156d3b6 Author: Tim Gardner <[email protected]> AuthorDate: Thu, 28 Apr 2011 11:00:30 -0600 Committer: Ingo Molnar <[email protected]> CommitDate: Fri, 29 Apr 2011 08:02:47 +0200
ioremap: Delay sanity check until after a successful mapping
While tracking down the reason for an ioremap() failure I was distracted by the WARN_ONCE() in __ioremap_caller().
Performing a WARN_ONCE() sanity check before the mapping is successful seems pointless if the caller sends bad values.
A case in point is when the BIOS provides erroneous screen_info values causing vesafb_probe() to request an outrageuous size. The WARN_ONCE is then wasted on bogosity. Move the warning to a point where the mapping has been successfully allocated.
Addresses:
http://bugs.launchpad.net/bugs/772042
--- arch/x86/mm/ioremap.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
arch/x86/mm/ioremap.c +7 -7
@@ -91,13 +91,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,return (__force void __iomem *)phys_to_virt (phys_addr);/* -* Check if the request spans more than any BAR in the iomem resource -* tree. -*/ -WARN_ONCE (iomem_map_sanity_check (phys_addr, size), -KERN_INFO "Info: mapping multiple BARs. Your kernel is fine." ); - -/* * Don't allow anybody to remap normal RAM that we're using.. */ last_pfn = last_addr >>PAGE_SHIFT ;
@@ -170,6 +163,13 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr, ret_addr = (void __iomem *) (vaddr + offset);mmiotrace_ioremap (unaligned_phys_addr, unaligned_size, ret_addr); +/* +* Check if the request spans more than any BAR in the iomem resource +* tree. +*/ +WARN_ONCE (iomem_map_sanity_check (unaligned_phys_addr, unaligned_size), +KERN_INFO "Info: mapping multiple BARs. Your kernel is fine." ); +return ret_addr; err_free_area:free_vm_area (area);