[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20181130161127.4e936864@mschwideX1>
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