From: Zachary Amsden <zach@vmware.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch -mm 1/2] i386: add ptep_test_and_clear_{dirty,young}
Date: Mon, 26 Mar 2007 12:20:21 -0800 [thread overview]
Message-ID: <46082B05.9050602@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0703260721490.18961@blonde.wat.veritas.com>
Hugh Dickins wrote:
> On Sun, 25 Mar 2007, Zachary Amsden wrote:
>
>> If you actually clear the bit, you need to:
>>
>> + pte_update_defer(vma->vm_mm, addr, ptep);
>>
>> The reason is, when updating PTEs, the hypervisor must be notified. Using
>> atomic operations to do this is fine for all hypervisors I am aware of.
>> However, for hypervisors which shadow page tables, if these PTE modifications
>> are not trapped, you need a post-modification call to fulfill the update of
>> the shadow page table.
>>
>
> Thanks for the very rapid response.
>
> So, David just needs to move the pte_update_defer out of
> ptep_clear_flush_* and into ptep_test_and_clear_*?
>
Yes.
> That leaves me wondering why you deleted ptep_test_and_clear_*
> (while leaving their __HAVE_ARCHes) in the first place?
>
Because raw use of them in the arch independent MM code would introduce
exactly this bug on i386, so leaving __HAVE_ARCH but leaving out the
definition would catch this case.
Zach
next prev parent reply other threads:[~2007-03-26 19:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 0:35 [patch -mm 1/2] i386: add ptep_test_and_clear_{dirty,young} David Rientjes
2007-03-26 0:35 ` [patch -mm 2/2] smaps: use ptep_test_and_clear_young David Rientjes
2007-03-26 5:53 ` [patch -mm 1/2] i386: add ptep_test_and_clear_{dirty,young} Hugh Dickins
2007-03-26 7:07 ` Zachary Amsden
2007-03-26 6:27 ` Hugh Dickins
2007-03-26 20:20 ` Zachary Amsden [this message]
2007-03-26 6:35 ` David Rientjes
2007-03-26 20:22 ` Zachary Amsden
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=46082B05.9050602@vmware.com \
--to=zach@vmware.com \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rientjes@google.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.