lkml.org 
[lkml]   [2010]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/4] x86: ioremap: fix physical address check
    (2010/06/15 5:16), Rolf Eike Beer wrote:
    > Kenji Kaneshige wrote:
    >> (2010/06/14 18:13), Kenji Kaneshige wrote:
    >>> Thank you Hiroyuki.
    >>>
    >>> So many bugs in ioremap()...
    >>>
    >>> Will try with those bugs fixed.
    >>>
    >>> Thanks,
    >>> Kenji Kaneshige
    >>
    >> The problem seems to be fixed by the following patch. This is still
    >> under testing. I will post the patch as v2 after testing.
    >>
    >> Thanks,
    >> Kenji Kaneshige
    >>
    >>
    >> Current x86 ioremap() doesn't handle physical address higher than
    >> 32-bit properly in X86_32 PAE mode. When physical address higher than
    >> 32-bit is passed to ioremap(), higher 32-bits in physical address is
    >> cleared wrongly. Due to this bug, ioremap() can map wrong address to
    >> linear address space.
    >>
    >> In my case, 64-bit MMIO region was assigned to a PCI device (ioat
    >> device) on my system. Because of the ioremap()'s bug, wrong physical
    >> address (instead of MMIO region) was mapped to linear address space.
    >> Because of this, loading ioatdma driver caused unexpected behavior
    >> (kernel panic, kernel hangup, ...).
    >>
    >> Signed-off-by: Kenji Kaneshige<kaneshige.kenji@jp.fujitsu.com>
    >>
    >> ---
    >> arch/x86/mm/ioremap.c | 11 +++++------
    >> include/linux/io.h | 4 ++--
    >> include/linux/vmalloc.h | 2 +-
    >> lib/ioremap.c | 10 +++++-----
    >> 4 files changed, 13 insertions(+), 14 deletions(-)
    >>
    >> Index: linux-2.6.34/arch/x86/mm/ioremap.c
    >> ===================================================================
    >> --- linux-2.6.34.orig/arch/x86/mm/ioremap.c
    >> +++ linux-2.6.34/arch/x86/mm/ioremap.c
    >> @@ -62,7 +62,8 @@ int ioremap_change_attr(unsigned long va
    >> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
    >> unsigned long size, unsigned long prot_val, void *caller)
    >> {
    >> - unsigned long pfn, offset, vaddr;
    >> + u64 pfn, last_pfn;
    >> + unsigned long offset, vaddr;
    >> resource_size_t last_addr;
    >> const resource_size_t unaligned_phys_addr = phys_addr;
    >> const unsigned long unaligned_size = size;
    >
    > Why do you use u64 and not resource_size_t for those? That way this would not
    > be needlessly big for "real" 32 bit platforms.

    Thank you for your comment. The reason was I found other code that uses
    u64 for pfn in other code. But yes, I will change that.

    Thanks,
    Kenji Kaneshige




    \
     
     \ /
      Last update: 2010-06-15 04:37    [W:0.026 / U:92.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site