On Wed, Dec 16, 2020 at 5:47 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> In preparation for adding a mmap_assert_locked() check in
> __get_user_pages(), teach the mmap_assert_*locked() helpers that it's fine
> to operate on an mm without locking in the middle of execve() as long as
> it hasn't been installed on a process yet.
>
> Existing code paths that do this are (reverse callgraph):
>
> get_user_pages_remote
> get_arg_page
> copy_strings
> copy_string_kernel
> remove_arg_zero
> tomoyo_dump_page
> tomoyo_print_bprm
> tomoyo_scan_bprm
> tomoyo_environ
Sorry, can you please kill both this patch and the following one
("mm/gup: assert that the mmap lock is held in __get_user_pages()")
from the mm tree?
I'll send new stuff (a new iteration of
https://lore.kernel.org/linux-mm/20201016225713.1971256-1-jannh@xxxxxxxxxx/
"[PATCH resend v3 0/2] Broad write-locking of nascent mm in execve",
followed by a resend of "mm/gup: assert that the mmap lock is held in
__get_user_pages()") when it's ready.
As I noted in the cover letter of that thing, which was meant to
replace this patch (but isn't ready yet - yeah, I should get back to
that...), this approach doesn't really work because bprm->vma is used
after the switch to the new mm.
Sorry about the mess... :/
I guess the next time this happens, I should just immediately email
you requesting that the queued-up patches should be dropped once an
issue is identified...
