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] [day] [month] [year] [list]
Date:   Fri, 30 Nov 2018 16:11:27 +0100
From:   Martin Schwidefsky <schwidefsky@...ibm.com>
To:     Sasha Levin <sashal@...nel.org>
Cc:     stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 4.19 13/73] s390/mm: fix mis-accounting of
 pgtable_bytes

On Wed, 14 Nov 2018 17:21:07 -0500
Sasha Levin <sashal@...nel.org> wrote:

> From: Martin Schwidefsky <schwidefsky@...ibm.com>
> 
> [ Upstream commit e12e4044aede97974f2222eb7f0ed726a5179a32 ]
> 
> 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: Li Wang <liwang@...hat.com>
> Tested-by: Li Wang <liwang@...hat.com>
> Signed-off-by: Martin Schwidefsky <schwidefsky@...ibm.com>
> Signed-off-by: Sasha Levin <sashal@...nel.org>

The fix for the page table accounting problem initially had four git commits:
a8874e7e8a "mm: make the __PAGETABLE_PxD_FOLDED defines non-empty"
1071fc5779 "mm: introduce mm_[p4d|pud|pmd]_folded"
6d212db119 "mm: add mm_pxd_folded checks to pgtable_bytes accounting functions"
e12e4044ae "s390/mm: fix mis-accounting of pgtable_bytes"

In the meantime a fifth git commit is needed to really fix it:
814cedbc0b "s390/mm: correct pgtable_bytes on page table downgrade"

The autoselect mechanism only pick up one of the initial four patches.
Not good. May I ask *WHY* this patch was picked out of the blue?

Same for 4.18-stable.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ