Re: [PATCH] mm/hugetlb.c: fix unnecessary address expansion of pmd sharing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/1/21 1:56 AM, Mike Kravetz wrote:
On 12/29/20 1:20 PM, Mike Kravetz wrote:
On 12/28/20 8:21 PM, Li Xinhai wrote:
The current code would unnecessarily expand the address range. Consider
one example, (start, end) = (1G-2M, 3G+2M), and  (vm_start, vm_end) =
(1G-4M, 3G+4M), the expected adjustment should be keep (1G-2M, 3G+2M)
without expand. But the current result will be (1G-4M, 3G+4M). Actually,
the range (1G-4M, 1G) and (3G, 3G+4M) would never been involved in pmd
sharing.

After this patch, if pud aligned *start across vm_start, then we know the
*start and vm_start are in same pud_index, and vm_start is not pud
aligned, so don't adjust *start. Same logic applied to *end.

Fixes: commit 75802ca66354 ("mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible")
Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
Cc: Peter Xu <peterx@xxxxxxxxxx>
Signed-off-by: Li Xinhai <lixinhai.lxh@xxxxxxxxx>

Thank you.  That does indeed fix an issue in the current code.

Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>

Upon further thought, this patch also expands the passed range when not
necessary.  Consider the example (start, end) = (1G-6M, 1G-4M), and
(vm_start, vm_end) = (1G, 1G-2M).  This patch would adjust the range to
(1G, 1G-4M).  However, no adjustment should be performed as no sharing
is possible.

correct, my previous patch did not fully fix the issue.

Above example maybe typo for vm_start, vm_end. The issue didn't fixed by my patch would be with another example, (vm_start, vm_end) = (1G-8M, 1G+2M), (start, end) = (1G-6M, 1G-4M), end should not be adjusted to 1G, although after adjust it still below vm_end.

Below is proposed code to address the issue.  I'm not sending a formal
patch yet as I would like comments on the code first.  It is not a critical
issue and any fix can wait a bit.

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7e89f31d7ef8..41ccec617f74 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5264,16 +5264,19 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
  	if (!(vma->vm_flags & VM_MAYSHARE))
  		return;
- /* Extend the range to be PUD aligned for a worst case scenario */
-	a_start = ALIGN_DOWN(*start, PUD_SIZE);
-	a_end = ALIGN(*end, PUD_SIZE);
-
  	/*
-	 * Intersect the range with the vma range, since pmd sharing won't be
-	 * across vma after all
+	 * Check if start and end are within a PUD aligned range of the
+	 * vma.  If they are, then adjust to PUD alignment.
  	 */
-	*start = max(vma->vm_start, a_start);
-	*end = min(vma->vm_end, a_end);
+	a_start = ALIGN_DOWN(*start, PUD_SIZE);
+	a_end = ALIGN(*start, PUD_SIZE);
+	if (range_in_vma(vma, a_start, a_end))
+		*start = a_start;
+
+	a_start = ALIGN_DOWN(*end, PUD_SIZE);
+	a_end = ALIGN(*end, PUD_SIZE);
+	if (range_in_vma(vma, a_start, a_end))
+		*end = a_end;
  }
/*

Now, this fully fixed the issue.

One thing to be sure is that the (start, end) as input parameter must already within vma's range, although the range_in_vma test() can cover the out of range cases.

Reviewed-by: Li Xinhai <lixinhai.lxh@xxxxxxxxx>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux