All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list
@ 2016-01-07 22:35 Mike Kravetz
  2016-01-07 23:13   ` Andrew Morton
  0 siblings, 1 reply; 5+ messages in thread
From: Mike Kravetz @ 2016-01-07 22:35 UTC (permalink / raw)
  To: linux-kernel, linux-mm, Hillf Danton, Andrew Morton
  Cc: Hugh Dickins, Naoya Horiguchi, Davidlohr Bueso, Dave Hansen,
	Mike Kravetz, stable, [4.3]

Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.
The argument end is of type pgoff_t.  It was being converted to a
vaddr offset and passed to unmap_hugepage_range.  However, end
was also being used as an argument to the vma_interval_tree_foreach
controlling loop.  In addition, the conversion of end to vaddr offset
was incorrect.

Fixes: 1bfad99ab (" hugetlbfs: hugetlb_vmtruncate_list() needs to take a range")
Cc: stable@vger.kernel.org [4.3]
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 fs/hugetlbfs/inode.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 0444760..89abdc9 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -461,8 +461,12 @@ hugetlb_vmdelete_list(struct rb_root *root, pgoff_t start, pgoff_t end)
 	 * end == 0 indicates that the entire range after
 	 * start should be unmapped.
 	 */
-	vma_interval_tree_foreach(vma, root, start, end ? end : ULONG_MAX) {
+	if (!end)
+		end = ULONG_MAX;
+
+	vma_interval_tree_foreach(vma, root, start, end) {
 		unsigned long v_offset;
+		unsigned long v_end;
 
 		/*
 		 * Can the expression below overflow on 32-bit arches?
@@ -475,15 +479,12 @@ hugetlb_vmdelete_list(struct rb_root *root, pgoff_t start, pgoff_t end)
 		else
 			v_offset = 0;
 
-		if (end) {
-			end = ((end - start) << PAGE_SHIFT) +
-			       vma->vm_start + v_offset;
-			if (end > vma->vm_end)
-				end = vma->vm_end;
-		} else
-			end = vma->vm_end;
+		v_end = (end - vma->vm_pgoff) << PAGE_SHIFT;
+		if (v_end > vma->vm_end)
+			v_end = vma->vm_end;
 
-		unmap_hugepage_range(vma, vma->vm_start + v_offset, end, NULL);
+		unmap_hugepage_range(vma, vma->vm_start + v_offset, v_end,
+									NULL);
 	}
 }
 
-- 
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>

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list
  2016-01-07 22:35 [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list Mike Kravetz
@ 2016-01-07 23:13   ` Andrew Morton
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2016-01-07 23:13 UTC (permalink / raw)
  To: Mike Kravetz
  Cc: linux-kernel, linux-mm, Hillf Danton, Hugh Dickins,
	Naoya Horiguchi, Davidlohr Bueso, Dave Hansen, stable

On Thu,  7 Jan 2016 14:35:37 -0800 Mike Kravetz <mike.kravetz@oracle.com> wrote:

> Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.
> The argument end is of type pgoff_t.  It was being converted to a
> vaddr offset and passed to unmap_hugepage_range.  However, end
> was also being used as an argument to the vma_interval_tree_foreach
> controlling loop.  In addition, the conversion of end to vaddr offset
> was incorrect.

Could we please have a description of the user-visible effects of the
bug?  It's always needed for -stable things.  And for all bugfixes, really.

(stable@vger.kernel.org[4.3] isn't an email address btw - my client barfed)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list
@ 2016-01-07 23:13   ` Andrew Morton
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2016-01-07 23:13 UTC (permalink / raw)
  To: Mike Kravetz
  Cc: linux-kernel, linux-mm, Hillf Danton, Hugh Dickins,
	Naoya Horiguchi, Davidlohr Bueso, Dave Hansen, stable

On Thu,  7 Jan 2016 14:35:37 -0800 Mike Kravetz <mike.kravetz@oracle.com> wrote:

> Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.
> The argument end is of type pgoff_t.  It was being converted to a
> vaddr offset and passed to unmap_hugepage_range.  However, end
> was also being used as an argument to the vma_interval_tree_foreach
> controlling loop.  In addition, the conversion of end to vaddr offset
> was incorrect.

Could we please have a description of the user-visible effects of the
bug?  It's always needed for -stable things.  And for all bugfixes, really.

(stable@vger.kernel.org[4.3] isn't an email address btw - my client barfed)

--
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>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list
  2016-01-07 23:13   ` Andrew Morton
@ 2016-01-07 23:51     ` Mike Kravetz
  -1 siblings, 0 replies; 5+ messages in thread
From: Mike Kravetz @ 2016-01-07 23:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, Hillf Danton, Hugh Dickins,
	Naoya Horiguchi, Davidlohr Bueso, Dave Hansen, stable

On 01/07/2016 03:13 PM, Andrew Morton wrote:
> On Thu,  7 Jan 2016 14:35:37 -0800 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 
>> Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.
>> The argument end is of type pgoff_t.  It was being converted to a
>> vaddr offset and passed to unmap_hugepage_range.  However, end
>> was also being used as an argument to the vma_interval_tree_foreach
>> controlling loop.  In addition, the conversion of end to vaddr offset
>> was incorrect.
> 
> Could we please have a description of the user-visible effects of the
> bug?  It's always needed for -stable things.  And for all bugfixes, really.
> 
> (stable@vger.kernel.org[4.3] isn't an email address btw - my client barfed)

Will do.

As I stare at the code to come up with user visible effects, I am not
convinced the fix is correct.  An update will come after more study.

-- 
Mike Kravetz

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list
@ 2016-01-07 23:51     ` Mike Kravetz
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Kravetz @ 2016-01-07 23:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, Hillf Danton, Hugh Dickins,
	Naoya Horiguchi, Davidlohr Bueso, Dave Hansen, stable

On 01/07/2016 03:13 PM, Andrew Morton wrote:
> On Thu,  7 Jan 2016 14:35:37 -0800 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 
>> Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.
>> The argument end is of type pgoff_t.  It was being converted to a
>> vaddr offset and passed to unmap_hugepage_range.  However, end
>> was also being used as an argument to the vma_interval_tree_foreach
>> controlling loop.  In addition, the conversion of end to vaddr offset
>> was incorrect.
> 
> Could we please have a description of the user-visible effects of the
> bug?  It's always needed for -stable things.  And for all bugfixes, really.
> 
> (stable@vger.kernel.org[4.3] isn't an email address btw - my client barfed)

Will do.

As I stare at the code to come up with user visible effects, I am not
convinced the fix is correct.  An update will come after more study.

-- 
Mike Kravetz

--
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>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-01-07 23:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-07 22:35 [PATCH] mm/hugetlbfs Fix bugs in hugetlb_vmtruncate_list Mike Kravetz
2016-01-07 23:13 ` Andrew Morton
2016-01-07 23:13   ` Andrew Morton
2016-01-07 23:51   ` Mike Kravetz
2016-01-07 23:51     ` Mike Kravetz

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.