Messages in this thread Patch in this message | | | From | Vlastimil Babka <> | Subject | [RFC 05/11] mm/mmap/vma_merge: use the proper vma pointer in case 4 | Date | Fri, 24 Feb 2023 11:00:16 +0100 |
| |
Almost all cases now use the 'next' pointer for the vma following the merged area, and the cases diagram shows it as XXXX. Case 4 is different as it uses 'mid' and NNNN, so change it for consistency. No functional change.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz> --- mm/mmap.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c index 704afa278a98..1e4be7174964 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -851,9 +851,9 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags, * vma, PPPPPP is the prev vma specified, and NNNNNN the next vma after: * * AAAA AAAA AAAA - * PPPPPPNNNNNN PPPPPPNNNNNN PPPPPPNNNNNN + * PPPPPPNNNNNN PPPPPPXXXXXX PPPPPPNNNNNN * cannot merge might become might become - * PPNNNNNNNNNN PPPPPPPPPPNN + * PPXXXXXXXXXX PPPPPPPPPPNN * mmap, brk or case 4 below case 5 below * mremap move: * AAAA AAAA @@ -972,9 +972,9 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, res = next; if (prev && addr < prev->vm_end) { /* case 4 */ vma_end = addr; - adjust = mid; + adjust = next; adj_next = -(prev->vm_end - addr); - err = dup_anon_vma(mid, prev); + err = dup_anon_vma(next, prev); } else { vma = next; /* case 3 */ vma_start = addr; -- 2.39.2
| |