[14/40] mm/gup: assert that the mmap lock is held in __get_user_pages()

Commit Message

Andrew Morton Oct. 17, 2020, 11:14 p.m. UTC

From: Jann Horn <[e-mail]>
Subject: mm/gup: assert that the mmap lock is held in __get_user_pages()

After having cleaned up all GUP callers (except for the atomisp staging
driver, which currently gets mmap locking completely wrong [1]) to always
ensure that they hold the mmap lock when calling into GUP (unless the mm
is not yet globally visible), add an assertion to make sure it stays that
way going forward.

[1] https://lore.kernel.org/lkml/CAG48ez3tZAb9JVhw4T5e-i=[e-mail]/

Link: https://lkml.kernel.org/r/CAG48ez1GM==OnHpS=[e-mail]
Signed-off-by: Jann Horn <[e-mail]>
Reviewed-by: Jason Gunthorpe <[e-mail]>
Acked-by: Michel Lespinasse <[e-mail]>
Cc: "Eric W . Biederman" <[e-mail]>
Cc: John Hubbard <[e-mail]>
Cc: Mauro Carvalho Chehab <[e-mail]>
Cc: Sakari Ailus <[e-mail]>
Signed-off-by: Andrew Morton <[e-mail]>
---

 mm/gup.c |    2 ++
 1 file changed, 2 insertions(+)

Comments

Jann Horn Oct. 18, 2020, 1:28 a.m. UTC | #1

On Sun, Oct 18, 2020 at 1:14 AM Andrew Morton <[e-mail]> wrote:
> From: Jann Horn <[e-mail]>
> Subject: mm/gup: assert that the mmap lock is held in __get_user_pages()
>
> After having cleaned up all GUP callers (except for the atomisp staging
> driver, which currently gets mmap locking completely wrong [1]) to always
> ensure that they hold the mmap lock when calling into GUP (unless the mm
> is not yet globally visible), add an assertion to make sure it stays that
> way going forward.

Please hold this patch until the replacement for the previous patch in
the series (original patch
mmap-locking-api-dont-check-locking-if-the-mm-isnt-live-yet, which you
are already holding back, and which is replaced by the series
https://lore.kernel.org/linux-mm/[e-mail]/
"Broad write-locking of nascent mm in execve") has gone into the mm
tree.

Otherwise I believe that this mmap_assert_lock() will cause new
lockdep warnings in places like copy_strings().

(Going forward, is there something I should do differently if a
similar issue happens again with a series of patches that has already
landed in the mm tree but where, after further discussion, parts
should be replaced?)


> [1] https://lore.kernel.org/lkml/CAG48ez3tZAb9JVhw4T5e-i=[e-mail]/
>
> Link: https://lkml.kernel.org/r/CAG48ez1GM==OnHpS=[e-mail]
> Signed-off-by: Jann Horn <[e-mail]>
> Reviewed-by: Jason Gunthorpe <[e-mail]>
> Acked-by: Michel Lespinasse <[e-mail]>
> Cc: "Eric W . Biederman" <[e-mail]>
> Cc: John Hubbard <[e-mail]>
> Cc: Mauro Carvalho Chehab <[e-mail]>
> Cc: Sakari Ailus <[e-mail]>
> Signed-off-by: Andrew Morton <[e-mail]>
> ---
>
>  mm/gup.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> --- a/mm/gup.c~mm-gup-assert-that-the-mmap-lock-is-held-in-__get_user_pages
> +++ a/mm/gup.c
> @@ -1027,6 +1027,8 @@ static long __get_user_pages(struct mm_s
>         struct vm_area_struct *vma = NULL;
>         struct follow_page_context ctx = { NULL };
>
> +       mmap_assert_locked(mm);
> +
>         if (!nr_pages)
>                 return 0;
>
> _

Patch

--- a/mm/gup.c~mm-gup-assert-that-the-mmap-lock-is-held-in-__get_user_pages
+++ a/mm/gup.c
@@ -1027,6 +1027,8 @@  static long __get_user_pages(struct mm_s
 	struct vm_area_struct *vma = NULL;
 	struct follow_page_context ctx = { NULL };
 
+	mmap_assert_locked(mm);
+
 	if (!nr_pages)
 		return 0;