linux-kernel - Re: [PATCH] s390/mm: fix pud table accounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Nov 2017 10:17:08 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Heiko Carstens <heiko.carstens@...ibm.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-next@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Gerald Schaefer <gerald.schaefer@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH] s390/mm: fix pud table accounting

On Fri 03-11-17 10:05:51, Heiko Carstens wrote:
> With "mm: account pud page tables" and "mm: consolidate page table
> accounting" pud page table accounting was introduced which now results
> in tons of warnings like this one on s390:
> 
> BUG: non-zero pgtables_bytes on freeing mm: -16384
> 
> Reason for this are our run-time folded page tables: by default new
> processes start with three page table levels where the allocated pgd
> is the same as the first pud. In this case there won't ever be a pud
> allocated and therefore mm_inc_nr_puds() will also never be called.
> 
> However when freeing the address space free_pud_range() will call
> exactly once mm_dec_nr_puds() which leads to misaccounting.
> 
> Therefore call mm_inc_nr_puds() within init_new_context() to fix
> this. This is the same like we have it already for processes that run
> with two page table levels (aka compat processes).
> 
> While at it also adjust the comment, since there is no "mm->nr_pmds"
> anymore.

Subtle...

Thanks for the fix, I didn't have any idea about this when reviewing.

> Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Cc: Michal Hocko <mhocko@...e.com>
> Cc: Gerald Schaefer <gerald.schaefer@...ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>
> Signed-off-by: Heiko Carstens <heiko.carstens@...ibm.com>
> ---
>  arch/s390/include/asm/mmu_context.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h
> index 3c9abedc323c..4f943d58cbac 100644
> --- a/arch/s390/include/asm/mmu_context.h
> +++ b/arch/s390/include/asm/mmu_context.h
> @@ -43,6 +43,8 @@ static inline int init_new_context(struct task_struct *tsk,
>  		mm->context.asce_limit = STACK_TOP_MAX;
>  		mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
>  				   _ASCE_USER_BITS | _ASCE_TYPE_REGION3;
> +		/* pgd_alloc() did not account this pud */
> +		mm_inc_nr_puds(mm);
>  		break;
>  	case -PAGE_SIZE:
>  		/* forked 5-level task, set new asce with new_mm->pgd */
> @@ -58,7 +60,7 @@ static inline int init_new_context(struct task_struct *tsk,
>  		/* forked 2-level compat task, set new asce with new mm->pgd */
>  		mm->context.asce = __pa(mm->pgd) | _ASCE_TABLE_LENGTH |
>  				   _ASCE_USER_BITS | _ASCE_TYPE_SEGMENT;
> -		/* pgd_alloc() did not increase mm->nr_pmds */
> +		/* pgd_alloc() did not account this pmd */
>  		mm_inc_nr_pmds(mm);
>  	}
>  	crst_table_init((unsigned long *) mm->pgd, pgd_entry_type(mm));
> -- 
> 2.13.5
> 

-- 
Michal Hocko
SUSE Labs