From: Andrea Arcangeli <aarcange@redhat.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: mmu notifier calls in apply_to_page_range()
Date: Fri, 9 Jul 2010 18:22:55 +0200 [thread overview]
Message-ID: <20100709162255.GA5741@random.random> (raw)
In-Reply-To: <4C37458B.8040408@goop.org>
On Fri, Jul 09, 2010 at 08:51:39AM -0700, Jeremy Fitzhardinge wrote:
> Yes, but apply_to_page_range isn't necessarily making changes which
> requires that teardown/refill. The most common user is vmalloc, which
> is just using a side-effect of apply_to_page_range to make sure that all
> the intermediate levels of the pagetable are allocated over the
> vmalloced range. I think all the other users of it are within Xen code.
> In particular, we're using it in the gntdev driver, which also uses mmu
> notifiers to keep grant mappings in sync with process mappings, so the
> recursive mmu notifier call is causing problems.
>
> It seems to me that apply_to_page_range should be agnostic to its use,
> and its up to its callers to do any appropriate mmu notifier work.
> Would you be happy with a patch to remove those calls?
mmu notifier only relevant for userland mappings, not kernel
mappings. I don't know about the xen use, but for vmalloc certainly it
can't be a problem to remove those two mmu notifier invalidates.
Only bit that is worrysome is the mm == &init_mm
pte_alloc_kernel|pte_alloc_map_lock. That seems to imply it may also
be used to mangle over userland. But apparently all users are passing
&init_mm as expected. I guess if you remove the mm parameter and you
default to &init_mm definitely there will be no risk in removing the
mmu notifier range_start/end invalidates.
next prev parent reply other threads:[~2010-07-09 16:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 15:06 mmu notifier calls in apply_to_page_range() Jeremy Fitzhardinge
2010-07-09 15:12 ` Andrea Arcangeli
2010-07-09 15:51 ` Jeremy Fitzhardinge
2010-07-09 16:22 ` Andrea Arcangeli [this message]
2010-07-09 17:30 ` Jeremy Fitzhardinge
2010-07-09 17:36 ` Andrea Arcangeli
2010-07-09 17:41 ` Jeremy Fitzhardinge
2010-07-09 18:31 ` Andrea Arcangeli
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=20100709162255.GA5741@random.random \
--to=aarcange@redhat.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
/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.