summaryrefslogtreecommitdiffstats
path: root/arch/x86/xen/mmu.h
diff options
context:
space:
mode:
authorJeremy Fitzhardinge <jeremy@goop.org>2008-10-08 13:01:39 -0700
committerIngo Molnar <mingo@elte.hu>2008-10-09 14:25:19 +0200
commiteefb47f6a1e855653d275cb90592a3587ea93a09 (patch)
treef6b5b611a8900d975874ab0ac9e7f5df935ef862 /arch/x86/xen/mmu.h
parentd19c8e516e0a17e049bcfbe96f86e040254ddf14 (diff)
downloadlinux-eefb47f6a1e855653d275cb90592a3587ea93a09.tar.gz
linux-eefb47f6a1e855653d275cb90592a3587ea93a09.tar.bz2
linux-eefb47f6a1e855653d275cb90592a3587ea93a09.zip
xen: use spin_lock_nest_lock when pinning a pagetable
When pinning/unpinning a pagetable with split pte locks, we can end up holding multiple pte locks at once (we need to hold the locks while there's a pending batched hypercall affecting the pte page). Because all the pte locks are in the same lock class, lockdep thinks that we're potentially taking a lock recursively. This warning is spurious because we always take the pte locks while holding mm->page_table_lock. lockdep now has spin_lock_nest_lock to express this kind of dominant lock use, so use it here so that lockdep knows what's going on. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'arch/x86/xen/mmu.h')
-rw-r--r--arch/x86/xen/mmu.h3
1 files changed, 0 insertions, 3 deletions
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 0f59bd03f9e3..98d71659da5a 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -18,9 +18,6 @@ void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next);
void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm);
void xen_exit_mmap(struct mm_struct *mm);
-void xen_pgd_pin(pgd_t *pgd);
-//void xen_pgd_unpin(pgd_t *pgd);
-
pteval_t xen_pte_val(pte_t);
pmdval_t xen_pmd_val(pmd_t);
pgdval_t xen_pgd_val(pgd_t);