From: Mike Kravetz <mike.kravetz@oracle.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: [PATCH] mm/hugetlbfs Fix bugs in fallocate hole punch of areas with holes
Date: Fri, 30 Oct 2015 16:32:12 -0700 [thread overview]
Message-ID: <1446247932-11348-1-git-send-email-mike.kravetz@oracle.com> (raw)
Hugh Dickins pointed out problems with the new hugetlbfs fallocate
hole punch code. These problems are in the routine remove_inode_hugepages
and mostly occur in the case where there are holes in the range of
pages to be removed. These holes could be the result of a previous hole
punch or simply sparse allocation.
remove_inode_hugepages handles both hole punch and truncate operations.
Page index handling was fixed/cleaned up so that holes are properly
handled. In addition, code was changed to ensure multiple passes of the
address range only happens in the truncate case. More comments were added
to explain the different actions in each case. A cond_resched() was added
after removing up to PAGEVEC_SIZE pages.
Some totally unnecessary code in hugetlbfs_fallocate() that remained from
early development was also removed.
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
fs/hugetlbfs/inode.c | 44 +++++++++++++++++++++++++++++---------------
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 316adb9..30cf534 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -368,10 +368,25 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
lookup_nr = end - next;
/*
- * This pagevec_lookup() may return pages past 'end',
- * so we must check for page->index > end.
+ * When no more pages are found, take different action for
+ * hole punch and truncate.
+ *
+ * For hole punch, this indicates we have removed each page
+ * within the range and are done. Note that pages may have
+ * been faulted in after being removed in the hole punch case.
+ * This is OK as long as each page in the range was removed
+ * once.
+ *
+ * For truncate, we need to make sure all pages within the
+ * range are removed when exiting this routine. We could
+ * have raced with a fault that brought in a page after it
+ * was first removed. Check the range again until no pages
+ * are found.
*/
if (!pagevec_lookup(&pvec, mapping, next, lookup_nr)) {
+ if (!truncate_op)
+ break;
+
if (next == start)
break;
next = start;
@@ -382,19 +397,23 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
struct page *page = pvec.pages[i];
u32 hash;
+ /*
+ * The page (index) could be beyond end. This is
+ * only possible in the punch hole case as end is
+ * LLONG_MAX for truncate.
+ */
+ if (page->index >= end) {
+ next = end; /* we are done */
+ break;
+ }
+ next = page->index;
+
hash = hugetlb_fault_mutex_hash(h, current->mm,
&pseudo_vma,
mapping, next, 0);
mutex_lock(&hugetlb_fault_mutex_table[hash]);
lock_page(page);
- if (page->index >= end) {
- unlock_page(page);
- mutex_unlock(&hugetlb_fault_mutex_table[hash]);
- next = end; /* we are done */
- break;
- }
-
/*
* If page is mapped, it was faulted in after being
* unmapped. Do nothing in this race case. In the
@@ -423,15 +442,13 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
}
}
- if (page->index > next)
- next = page->index;
-
++next;
unlock_page(page);
mutex_unlock(&hugetlb_fault_mutex_table[hash]);
}
huge_pagevec_release(&pvec);
+ cond_resched();
}
if (truncate_op)
@@ -647,9 +664,6 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
if (!(mode & FALLOC_FL_KEEP_SIZE) && offset + len > inode->i_size)
i_size_write(inode, offset + len);
inode->i_ctime = CURRENT_TIME;
- spin_lock(&inode->i_lock);
- inode->i_private = NULL;
- spin_unlock(&inode->i_lock);
out:
mutex_unlock(&inode->i_mutex);
return error;
--
2.4.3
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2015-10-30 23:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 23:32 Mike Kravetz [this message]
2015-11-09 6:57 ` [PATCH] mm/hugetlbfs Fix bugs in fallocate hole punch of areas with holes Naoya Horiguchi
2015-11-09 7:09 ` Hugh Dickins
2015-11-09 23:24 ` Mike Kravetz
-- strict thread matches above, loose matches on Subject: below --
2015-10-31 5:07 Hillf Danton
2015-10-31 17:53 ` Mike Kravetz
2015-11-02 2:50 ` Hillf Danton
2015-11-02 17:39 ` Mike Kravetz
2015-11-02 21:40 ` Andrew Morton
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=1446247932-11348-1-git-send-email-mike.kravetz@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).