From 5b4494896cb379b0304ba8320589f2ffd08a7b31 Mon Sep 17 00:00:00 2001 From: Florian Rommel Date: Mon, 9 May 2022 18:20:53 -0700 Subject: mmap locking API: fix missed mmap_sem references in comments Commit c1e8d7c6a7a6 ("mmap locking API: convert mmap_sem comments") missed replacing some references of mmap_sem by mmap_lock due to misspelling (mm_sem instead of mmap_sem). Link: https://lkml.kernel.org/r/20220503113333.214124-1-mail@florommel.de Signed-off-by: Florian Rommel Signed-off-by: Andrew Morton --- mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'mm/mmap.c') diff --git a/mm/mmap.c b/mm/mmap.c index d7e120ad5825..7f7d982721b9 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1285,7 +1285,7 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * the same as 'old', the other will be the new one that is trying * to share the anon_vma. * - * NOTE! This runs with mm_sem held for reading, so it is possible that + * NOTE! This runs with mmap_lock held for reading, so it is possible that * the anon_vma of 'old' is concurrently in the process of being set up * by another page fault trying to merge _that_. But that's ok: if it * is being set up, that automatically means that it will be a singleton @@ -1299,7 +1299,7 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * * We also make sure that the two vma's are compatible (adjacent, * and with the same memory policies). That's all stable, even with just - * a read lock on the mm_sem. + * a read lock on the mmap_lock. */ static struct anon_vma *reusable_anon_vma(struct vm_area_struct *old, struct vm_area_struct *a, struct vm_area_struct *b) { -- cgit v1.2.3