Re: [PATCH] x86: fix virt_addr_valid() with CONFIG_DEBUG_VIRTUAL=y

From: Vegard Nossum
Date: Wed Oct 01 2008 - 07:15:44 EST


On Wed, Oct 1, 2008 at 1:06 PM, Jiri Slaby <jirislaby@xxxxxxxxx> wrote:
> On 10/01/2008 12:47 PM, Vegard Nossum wrote:
>> Hi,
>>
>> Fix for tip/x86/mm-debug (commit 59ea746337c69f6a5f1bc4d5e8544b3cbf12f801).
>> I'm not sure if choice of names/structure is entirely correct, comments are
>> appreciated.
>
>
>> From 01613a1949de51c7ab9d0acaaa9a5444722a5cfa Mon Sep 17 00:00:00 2001
>> From: Vegard Nossum <vegardno@xxxxxxxxxxxxxx>
>> Date: Wed, 1 Oct 2008 12:36:34 +0200
>> Subject: [PATCH] x86: fix virt_addr_valid() with CONFIG_DEBUG_VIRTUAL=y
>>
>> virt_addr_valid() calls __pa(), which calls __phys_addr(). With
>> CONFIG_DEBUG_VIRTUAL=y, __phys_addr() will kill the kernel if the
>> address *isn't* valid. That's clearly wrong for virt_addr_valid().
>>

...

>> --- a/include/asm-x86/page_64.h
>> +++ b/include/asm-x86/page_64.h
>> @@ -69,6 +69,7 @@ extern unsigned long max_pfn;
>> extern unsigned long phys_base;
>>
>> extern unsigned long __phys_addr(unsigned long);
>> +#define __phys_addr_nodebug(x) __phys_addr(x)
>> #define __phys_reloc_hide(x) (x)
>
> x86_64 is screwed in the same way, isn't it?

Hm. I didn't see any #ifdef CONFIG_DEBUG_VIRTUAL in the x86_64 code,
so I assumed it wasn't. But it seems that you are right (because the
checks, or at least some kind of checks, are _always_ performed on
x86_64 regardless of the CONFIG_DEBUG_VIRTUAL setting). Why doesn't
the checking in x86_64 code depend on DEBUG_VIRTUAL?

I will try to make another patch, thanks.


Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/