• Lorenzo Stoakes's avatar
    mm/mprotect: allow unfaulted VMAs to be unaccounted on mprotect() · 9b914329
    Lorenzo Stoakes authored
    When mprotect() is used to make unwritable VMAs writable, they have the
    VM_ACCOUNT flag applied and memory accounted accordingly.
    
    If the VMA has had no pages faulted in and is then made unwritable once
    again, it will remain accounted for, despite not being capable of
    extending memory usage.
    
    Consider:-
    
    ptr = mmap(NULL, page_size * 3, PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0);
    mprotect(ptr + page_size, page_size, PROT_READ | PROT_WRITE);
    mprotect(ptr + page_size, page_size, PROT_READ);
    
    The first mprotect() splits the range into 3 VMAs and the second fails to
    merge the three as the middle VMA has VM_ACCOUNT set and the others do
    not, rendering them unmergeable.
    
    This is unnecessary, since no pages have actually been allocated and the
    middle VMA is not capable of utilising more memory, thereby introducing
    unnecessary VMA fragmentation (and accounting for more memory than is
    necessary).
    
    Since we cannot efficiently determine which pages map to an anonymous VMA,
    we have to be very conservative - determining whether any pages at all
    have been faulted in, by checking whether vma->anon_vma is NULL.
    
    We can see that the lack of anon_vma implies that no anonymous pages are
    present as evidenced by vma_needs_copy() utilising this on fork to
    determine whether page tables need to be copied.
    
    The only place where anon_vma is set NULL explicitly is on fork with
    VM_WIPEONFORK set, however since this flag is intended to cause the child
    process to not CoW on a given memory range, it is right to interpret this
    as indicating the VMA has no faulted-in anonymous memory mapped.
    
    If the VMA was forked without VM_WIPEONFORK set, then anon_vma_fork() will
    have ensured that a new anon_vma is assigned (and correctly related to its
    parent anon_vma) should any pages be CoW-mapped.
    
    The overall operation is safe against races as we hold a write lock against
    mm->mmap_lock.
    
    If we could efficiently look up the VMA's faulted-in pages then we would
    unaccount all those pages not yet faulted in.  However as the original
    comment alludes this simply isn't currently possible, so we are
    conservative and account all pages or none at all.
    
    Link: https://lkml.kernel.org/r/ad5540371a16623a069f03f4db1739f33cde1fab.1696921767.git.lstoakes@gmail.comSigned-off-by: default avatarLorenzo Stoakes <lstoakes@gmail.com>
    Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
    Acked-by: default avatarMike Rapoport (IBM) <rppt@kernel.org>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    9b914329
mprotect.c 22.8 KB