• Martin Schwidefsky's avatar
    s390/mm: fix mis-accounting of pgtable_bytes · e12e4044
    Martin Schwidefsky authored
    In case a fork or a clone system fails in copy_process and the error
    handling does the mmput() at the bad_fork_cleanup_mm label, the
    following warning messages will appear on the console:
    
      BUG: non-zero pgtables_bytes on freeing mm: 16384
    
    The reason for that is the tricks we play with mm_inc_nr_puds() and
    mm_inc_nr_pmds() in init_new_context().
    
    A normal 64-bit process has 3 levels of page table, the p4d level and
    the pud level are folded. On process termination the free_pud_range()
    function in mm/memory.c will subtract 16KB from pgtable_bytes with a
    mm_dec_nr_puds() call, but there actually is not really a pud table.
    
    One issue with this is the fact that pgtable_bytes is usually off
    by a few kilobytes, but the more severe problem is that for a failed
    fork or clone the free_pgtables() function is not called. In this case
    there is no mm_dec_nr_puds() or mm_dec_nr_pmds() that go together with
    the mm_inc_nr_puds() and mm_inc_nr_pmds in init_new_context().
    The pgtable_bytes will be off by 16384 or 32768 bytes and we get the
    BUG message. The message itself is purely cosmetic, but annoying.
    
    To fix this override the mm_pmd_folded, mm_pud_folded and mm_p4d_folded
    function to check for the true size of the address space.
    Reported-by: default avatarLi Wang <liwang@redhat.com>
    Tested-by: default avatarLi Wang <liwang@redhat.com>
    Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    e12e4044
mmu_context.h 3.86 KB