From: Jiri Slaby <jirislaby@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
Vegard Nossum <vegardno@ifi.uio.no>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: fix virt_addr_valid() with CONFIG_DEBUG_VIRTUAL=y
Date: Wed, 01 Oct 2008 22:01:00 +0200 [thread overview]
Message-ID: <48E3D6FC.7070709@gmail.com> (raw)
In-Reply-To: <20081001194655.GZ25711@one.firstfloor.org>
On 10/01/2008 09:46 PM, Andi Kleen wrote:
>> Anyway virt_addr_valid() is IMHO wrong. E.g. first modules VM address
>> 0xffffffffa0000000 is after __pa() 200M which is valid pfn after the shift even
>> on the flatmem model with enough memory.
>>
>> Am I missing something? What's the exact purpose of the virt_addr_valid()?
>
> I think it's supposed to be only used on direct mapping anyways (judging
> from a quick look a the users)
Then kmemcheck assumes something else. Citing:
* We need to be extremely careful not to follow any invalid pointers,
* because this function can be called for *any* possible address.
and the very first check is !virt_addr_valid(address).
> So not handling text mapping is ok, but don't panic on it.
It doesn't handle properly anything but text and direct mapping. Now it
oopses/causes BUG on that wrong cases.
I think we should set it down there that it was intended to be used only on
text/direct mapping and only for checking if there is a physical memory page
behind this kind of virtual address.
next prev parent reply other threads:[~2008-10-01 20:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 10:47 [PATCH] x86: fix virt_addr_valid() with CONFIG_DEBUG_VIRTUAL=y Vegard Nossum
2008-10-01 11:06 ` Jiri Slaby
2008-10-01 11:07 ` Jiri Slaby
2008-10-01 11:15 ` Vegard Nossum
2008-10-01 11:26 ` Jiri Slaby
2008-10-01 16:42 ` Vegard Nossum
2008-10-01 16:52 ` Andi Kleen
2008-10-01 19:32 ` Jiri Slaby
2008-10-01 19:46 ` Andi Kleen
2008-10-01 20:01 ` Jiri Slaby [this message]
2008-10-02 6:18 ` Vegard Nossum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48E3D6FC.7070709@gmail.com \
--to=jirislaby@gmail.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vegard.nossum@gmail.com \
--cc=vegardno@ifi.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.