From: Jiri Slaby <jirislaby@gmail.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Tejun Heo <htejun@gmail.com>, Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vegard Nossum <vegard.nossum@gmail.com>
Subject: Re: __virt_addr_valid vs virtual percpu areas
Date: Thu, 05 Mar 2009 00:19:29 +0100 [thread overview]
Message-ID: <49AF0C81.7060908@gmail.com> (raw)
In-Reply-To: <49AF075D.9070607@goop.org>
On 4.3.2009 23:57, Jeremy Fitzhardinge wrote:
> On i386, __virt_addr_valid() has the test:
>
> if (system_state != SYSTEM_BOOTING && is_vmalloc_addr((void *) x))
> return false;
>
>
> Why is the vmalloc area a valid virtual address while the system is
> booting?
It's not (in the meaning of virt_* functions), but while booting we
don't have variables used in VMALLOC_START and VMALLOC_END ready for use
on i386.
Maybe we can introduce more clever method/state which would say: hey,
vmalloc framework is up and running. And use instead (system_state !=
SYSTEM_BOOTING) hack.
> This is biting me because I need to translate percpu addresses
> to pfns, but I only bother doing the full pagetable walk if
> virt_addr_valid() is false (otherwise I just use __pa()).
Do you need to bother also with vmalloc space?
> Removing this test doesn't seem to harm anything at first glance. Is
> this OK to do in general (and can we quietly set fire to system_state
> while we're about it)?
I wouldn't do that, since vmalloc addr is not virt addr, again in the
meaning of virt_* functions. And the function wouldn't do the right
thing, at least in the RUNNING state anymore.
next prev parent reply other threads:[~2009-03-04 23:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 22:57 __virt_addr_valid vs virtual percpu areas Jeremy Fitzhardinge
2009-03-04 23:19 ` Jiri Slaby [this message]
2009-03-04 23:48 ` Jeremy Fitzhardinge
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=49AF0C81.7060908@gmail.com \
--to=jirislaby@gmail.com \
--cc=htejun@gmail.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vegard.nossum@gmail.com \
--cc=x86@kernel.org \
/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.