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

[<Stuart_Hayes@Dell.com>]

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/