FAILED: patch "[PATCH] mm/hugetlb: fix calculation of" failed to apply to 4.4-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 75802ca66354a39ab8e35822747cd08b3384a99a Mon Sep 17 00:00:00 2001
From: Peter Xu <[email protected]>
Date: Thu, 6 Aug 2020 23:26:11 -0700
Subject: [PATCH] mm/hugetlb: fix calculation of
adjust_range_if_pmd_sharing_possible
This is found by code observation only.
Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g).
Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge.
Mike said:
: With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect.
:
: We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. :
: However, I am fairly confident that adjust_range_if_pmd_sharing_possible : is only gong to be called in two cases:
:
: 1) for a single page
: 2) for range == entire vma
:
: In those cases, the current code should produce the correct results. :
: To be safe, let's just cc stable.
mm/hugetlb.c +10 -14
@@ -5314,25 +5314,21 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)void adjust_range_if_pmd_sharing_possible (struct vm_area_struct *vma,unsigned long *start,unsigned long *end) { -unsigned long check_addr; +unsigned long a_start, a_end;if (!(vma->vm_flags &VM_MAYSHARE ))return ; -for (check_addr = *start; check_addr < *end; check_addr +=PUD_SIZE ) { -unsigned long a_start = check_addr &PUD_MASK ; -unsigned long a_end = a_start +PUD_SIZE ; +/* 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 ); -/* -* If sharing is possible, adjust start/end if necessary. -*/ -if (range_in_vma (vma, a_start, a_end)) { -if (a_start < *start) - *start = a_start; -if (a_end > *end) - *end = a_end; - } - } +/* +* Intersect the range with the vma range, since pmd sharing won't be +* across vma after all +*/ + *start =max (vma->vm_start, a_start); + *end =min (vma->vm_end, a_end); }/*
Mike Kravetz
Reviewed-byQuoted 9 lines · On 8/19/20 5:21 AM, [email protected] wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
From d43b8a81c7f921aa52d55817390384053cd7be21 Mon Sep 17 00:00:00 2001
From: Peter Xu <[email protected]>
Date: Thu, 20 Aug 2020 10:38:02 -0700
Subject: [PATCH] mm/hugetlb: fix calculation of
adjust_range_if_pmd_sharing_possible
commit 75802ca66354a39ab8e35822747cd08b3384a99a upstream
This is found by code observation only.
Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g).
Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge.
Mike said:
: With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect.
:
: We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. :
: However, I am fairly confident that adjust_range_if_pmd_sharing_possible : is only gong to be called in two cases:
:
: 1) for a single page
: 2) for range == entire vma
:
: In those cases, the current code should produce the correct results. :
: To be safe, let's just cc stable.
--- mm/hugetlb.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-)
mm/hugetlb.c +11 -14
@@ -4257,6 +4257,7 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)return false; } +#define ALIGN_DOWN (x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))/* * Determine if start,end range within vma could be mapped by shared pmd. * If yes, adjust start and end to cover range associated with possible
@@ -4265,25 +4266,21 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)void adjust_range_if_pmd_sharing_possible (struct vm_area_struct *vma,unsigned long *start,unsigned long *end) { -unsigned long check_addr = *start; +unsigned long a_start, a_end;if (!(vma->vm_flags &VM_MAYSHARE ))return ; -for (check_addr = *start; check_addr < *end; check_addr +=PUD_SIZE ) { -unsigned long a_start = check_addr &PUD_MASK ; -unsigned long a_end = a_start +PUD_SIZE ; +/* 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 ); -/* -* If sharing is possible, adjust start/end if necessary. -*/ -if (range_in_vma (vma, a_start, a_end)) { -if (a_start < *start) - *start = a_start; -if (a_end > *end) - *end = a_end; - } - } +/* +* Intersect the range with the vma range, since pmd sharing won't be +* across vma after all +*/ + *start =max (vma->vm_start, a_start); + *end =min (vma->vm_end, a_end); }/*
Signature · 1 line
2.25.4
Greg KH
maintainerQuoted 58 lines · Mike Kravetz
Quoted 11 lines · On 8/19/20 5:21 AM, [email protected] wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
From
d43b8a81c7f921aa52d55817390384053cd7be21Mon Sep 17 00:00:00 2001From: Peter Xu <[email protected]>
Date: Thu, 20 Aug 2020 10:38:02 -0700
Subject: [PATCH] mm/hugetlb: fix calculation of
adjust_range_if_pmd_sharing_possiblecommit
75802ca66354a39ab8e35822747cd08b3384a99aupstreamThis is found by code observation only.
Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g).
Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge.
Mike said:
: With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect.
:
: We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. :
: However, I am fairly confident thatadjust_range_if_pmd_sharing_possible: is only gong to be called in two cases:
:
: 1) for a single page
: 2) for range == entire vma
:
: In those cases, the current code should produce the correct results. :
: To be safe, let's just cc stable.Fixes 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages")Signed-off-by Peter Xu <[email protected]>Signed-off-by Andrew Morton <[email protected]>Reviewed-by Mike Kravetz <[email protected]>Cc Andrea Arcangeli <[email protected]>Cc Matthew Wilcox <[email protected]>Cc <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Mike Kravetz <[email protected]>
Quoted 2 lines
--- mm/hugetlb.c | 25 +++++++++++--------------
Thanks for all of the backports, now queued up.
greg k-h