RE: page allocation/attributes question (i386/x86_64 specific)

Stuart_Hayes_at_Dell.com
Date: 06/30/05

  • Next message: John Lenz: "Re: [GIT PATCH] Driver core patches for 2.6.13-rc1"
    Date:	Thu, 30 Jun 2005 12:14:16 -0500
    To: <Stuart_Hayes@Dell.com>, <ak@suse.de>
    
    

    Hayes, Stuart wrote:
    > Andi Kleen wrote:
    >>
    >> I only fixed it for x86-64 correct. Does it work for you on x86-64?
    >>
    >> If yes then the changes could be brought over.
    >>
    >> What do you all need this for anyways?
    >>
    >> -Andi
    >
    > We need this because the NVidia driver uses change_page_attr() to
    > make pages non-cachable, which is causing systems to spontaneously
    > reboot when it gets a page that's in the first 8MB of memory.
    >
    > I'll look at x86_64. The problem was seen originally with i386, and
    > I haven't taken much time to look at the x86_64 stuff yet.
    >
    > Thanks,
    > Stuart

    Doesn't x86_64 map the kernel code into a different virtual address
    range than the direct mapping of physical memory--and __get_free_pages()
    returns a pointer to the direct mapping area rather than to the kernel
    text area? This would prevent the problem, because I assume the entire
    direct mapping of physical memory area is set to non-executable.

    The problem with i386 occurs because the kernel code and kernel memory
    is all mapped to the same virtual address range (at 0xC0000000), so
    kernel code, and free pages returned by __get_free_pages(), both reside
    in the same large page.

    So, if I understand correctly what's going on in x86_64, your fix
    wouldn't be applicable to i386. In x86_64, every large page has a
    correct "ref_prot" that is the normal setting for that page... but in
    i386, the kernel text area does not--it should ideally be split into
    small pages all the time if there are both kernel code & free pages
    residing in the same 2M area.

    Stuart

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: John Lenz: "Re: [GIT PATCH] Driver core patches for 2.6.13-rc1"

    Relevant Pages

    • Re: Is there some bug in ext3 in 2.4.25?
      ... but I've managed to test machine. ... >> all by the kernel code. ... >Sounds like bad memory to me. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: memory size
      ... Memory: 16116752k/16777216k available (1855k kernel code, 135136k reserved, ... 702k data, 164k init, 15335296k highmem) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • memory size
      ... Memory: 4673020k/5242880k available (1334k kernel code, 44532k reserved, ... 672k data, 156k init, 3800960k highmem) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.18-rc7-mm1 -- ppc64 crash in slab_node ??
      ... Memory: 2042288k/2097152k available (5752k kernel code, 55392k reserved, ... Thanks I'll push it into the testing system and see what happens. ...
      (Linux-Kernel)
    • Re: Kernel GPL Violations and How to Research
      ... > arch specific kernel code or drivers as well as matching function names, ... Linux USB Mass Storage Driver ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)