Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932485AbbHDT67 (ORCPT ); Tue, 4 Aug 2015 15:58:59 -0400 Received: from mga11.intel.com ([192.55.52.93]:20469 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754204AbbHDT6P (ORCPT ); Tue, 4 Aug 2015 15:58:15 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,611,1432623600"; d="scan'208";a="742164413" From: Matthew Wilcox To: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: "Kirill A. Shutemov" , willy@linux.intel.com Subject: [PATCH 08/11] thp: Fix zap_huge_pmd() for DAX Date: Tue, 4 Aug 2015 15:58:02 -0400 Message-Id: <1438718285-21168-9-git-send-email-matthew.r.wilcox@intel.com> X-Mailer: git-send-email 2.4.6 In-Reply-To: <1438718285-21168-1-git-send-email-matthew.r.wilcox@intel.com> References: <1438718285-21168-1-git-send-email-matthew.r.wilcox@intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3441 Lines: 107 From: "Kirill A. Shutemov" The original DAX code assumed that pgtable_t was a pointer, which isn't true on all architectures. Restructure the code to not rely on that assumption. Signed-off-by: Kirill A. Shutemov [further fixes from Matthew integrated into this patch] Signed-off-by: Matthew Wilcox --- mm/huge_memory.c | 71 +++++++++++++++++++++++++------------------------------- 1 file changed, 31 insertions(+), 40 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 326d17e..b51bed1 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1426,50 +1426,41 @@ out: int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr) { + pmd_t orig_pmd; spinlock_t *ptl; - int ret = 0; - if (__pmd_trans_huge_lock(pmd, vma, &ptl) == 1) { - pgtable_t pgtable; - pmd_t orig_pmd; - /* - * For architectures like ppc64 we look at deposited pgtable - * when calling pmdp_huge_get_and_clear. So do the - * pgtable_trans_huge_withdraw after finishing pmdp related - * operations. - */ - orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd, - tlb->fullmm); - tlb_remove_pmd_tlb_entry(tlb, pmd, addr); - if (vma_is_dax(vma)) { - if (is_huge_zero_pmd(orig_pmd)) { - pgtable = NULL; - } else { - spin_unlock(ptl); - return 1; - } - } else { - pgtable = pgtable_trans_huge_withdraw(tlb->mm, pmd); - } - if (is_huge_zero_pmd(orig_pmd)) { - atomic_long_dec(&tlb->mm->nr_ptes); - spin_unlock(ptl); + if (__pmd_trans_huge_lock(pmd, vma, &ptl) != 1) + return 0; + /* + * For architectures like ppc64 we look at deposited pgtable + * when calling pmdp_huge_get_and_clear. So do the + * pgtable_trans_huge_withdraw after finishing pmdp related + * operations. + */ + orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd, + tlb->fullmm); + tlb_remove_pmd_tlb_entry(tlb, pmd, addr); + if (vma_is_dax(vma)) { + spin_unlock(ptl); + if (is_huge_zero_pmd(orig_pmd)) put_huge_zero_page(); - } else { - struct page *page = pmd_page(orig_pmd); - page_remove_rmap(page); - VM_BUG_ON_PAGE(page_mapcount(page) < 0, page); - add_mm_counter(tlb->mm, MM_ANONPAGES, -HPAGE_PMD_NR); - VM_BUG_ON_PAGE(!PageHead(page), page); - atomic_long_dec(&tlb->mm->nr_ptes); - spin_unlock(ptl); - tlb_remove_page(tlb, page); - } - if (pgtable) - pte_free(tlb->mm, pgtable); - ret = 1; + } else if (is_huge_zero_pmd(orig_pmd)) { + pte_free(tlb->mm, pgtable_trans_huge_withdraw(tlb->mm, pmd)); + atomic_long_dec(&tlb->mm->nr_ptes); + spin_unlock(ptl); + put_huge_zero_page(); + } else { + struct page *page = pmd_page(orig_pmd); + page_remove_rmap(page); + VM_BUG_ON_PAGE(page_mapcount(page) < 0, page); + add_mm_counter(tlb->mm, MM_ANONPAGES, -HPAGE_PMD_NR); + VM_BUG_ON_PAGE(!PageHead(page), page); + pte_free(tlb->mm, pgtable_trans_huge_withdraw(tlb->mm, pmd)); + atomic_long_dec(&tlb->mm->nr_ptes); + spin_unlock(ptl); + tlb_remove_page(tlb, page); } - return ret; + return 1; } int move_huge_pmd(struct vm_area_struct *vma, struct vm_area_struct *new_vma, -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/