From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752513AbbJPWJa (ORCPT ); Fri, 16 Oct 2015 18:09:30 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37457 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752386AbbJPWJ2 (ORCPT ); Fri, 16 Oct 2015 18:09:28 -0400 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Dave Hansen , Naoya Horiguchi , Hugh Dickins , Davidlohr Bueso , Andrew Morton , Mike Kravetz Subject: [PATCH 3/3] mm/hugetlb: page faults check for fallocate hole punch in progress and wait Date: Fri, 16 Oct 2015 15:08:30 -0700 Message-Id: <1445033310-13155-4-git-send-email-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1445033310-13155-1-git-send-email-mike.kravetz@oracle.com> References: <1445033310-13155-1-git-send-email-mike.kravetz@oracle.com> X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At page fault time, check i_private which indicates a fallocate hole punch is in progress. If the fault falls within the hole, wait for the hole punch operation to complete before proceeding with the fault. Signed-off-by: Mike Kravetz --- mm/hugetlb.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 3c7db92..540d3a79 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3580,6 +3580,7 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, struct page *pagecache_page = NULL; struct hstate *h = hstate_vma(vma); struct address_space *mapping; + struct inode *inode = file_inode(vma->vm_file); int need_wait_lock = 0; address &= huge_page_mask(h); @@ -3603,6 +3604,42 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, idx = vma_hugecache_offset(h, vma, address); /* + * page faults could race with fallocate hole punch. If a page + * is faulted between unmap and deallocation, it will still remain + * in the punched hole. During hole punch operations, a hugetlb_falloc + * structure will be pointed to by i_private. If this fault is for + * a page in a hole being punched, wait for the operation to finish + * before proceeding. + * + * Even with this strategy, it is still possible for a page fault to + * race with hole punch. However, the race window is considerably + * smaller. + */ + if (unlikely(inode->i_private)) { + struct hugetlb_falloc *hugetlb_falloc; + + spin_lock(&inode->i_lock); + hugetlb_falloc = inode->i_private; + if (hugetlb_falloc && hugetlb_falloc->waitq && + idx >= hugetlb_falloc->start && + idx <= hugetlb_falloc->end) { + wait_queue_head_t *hugetlb_falloc_waitq; + DEFINE_WAIT(hugetlb_fault_wait); + + hugetlb_falloc_waitq = hugetlb_falloc->waitq; + prepare_to_wait(hugetlb_falloc_waitq, + &hugetlb_fault_wait, + TASK_UNINTERRUPTIBLE); + spin_unlock(&inode->i_lock); + schedule(); + + spin_lock(&inode->i_lock); + finish_wait(hugetlb_falloc_waitq, &hugetlb_fault_wait); + } + spin_unlock(&inode->i_lock); + } + + /* * Serialize hugepage allocation and instantiation, so that we don't * get spurious allocation failures if two CPUs race to instantiate * the same page in the page cache. -- 2.4.3