On 11/26/18 11:34 PM, Heiko Carstens wrote:
On Wed, Oct 31, 2018 at 01:36:23PM +0300, Kirill A. Shutemov wrote:
On Wed, Oct 31, 2018 at 11:09:44AM +0100, Heiko Carstens wrote:
On Wed, Oct 31, 2018 at 07:31:49AM +0100, Martin Schwidefsky wrote:
Thanks for testing. Unfortunately Heiko reported another issue yesterday
with the patch applied. This time the other way around:
BUG: non-zero pgtables_bytes on freeing mm: -16384
I am trying to understand how this can happen. For now I would like to
keep the patch on hold in case they need another change.
FWIW, Kirill: is there a reason why this "BUG:" output is done with
pr_alert() and not with VM_BUG_ON() or one of the WARN*() variants?
That would to get more information with DEBUG_VM and / or
panic_on_warn=1 set. At least for automated testing it would be nice
to have such triggers.
Stack trace is not helpful there. It will always show the exit path which
is useless.
So, even with the updated version of these patches I can flood dmesg
and the console with
BUG: non-zero pgtables_bytes on freeing mm: 16384
messages with this complex reproducer on s390:
echo "void main(void) {}" | gcc -m31 -xc -o compat - && ./compat
Besides that this needs to be fixed, I'd really like to see this
changed to either a printk_once() or a WARN_ON_ONCE() within
check_mm() so that an arbitrary user cannot flood the console.
E.g. something like the below. If there aren't any objections, I will
provide a proper patch with changelog, etc.
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff89c7b..d7aeec03c57f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -647,8 +647,8 @@ static void check_mm(struct mm_struct *mm)
}
if (mm_pgtables_bytes(mm))
- pr_alert("BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
- mm_pgtables_bytes(mm));
+ printk_once(KERN_ALERT "BUG: non-zero pgtables_bytes on freeing mm: %ld\n",
+ mm_pgtables_bytes(mm));
pr_alert_once ?
Guenter
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
