Re: [patch 94/95] mmap locking API: don't check locking if the mm isn't live yet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...



[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux