All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.