From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by kanga.kvack.org (Postfix) with ESMTP id E435D6B47B1 for ; Tue, 27 Nov 2018 06:47:18 -0500 (EST) Received: by mail-pl1-f199.google.com with SMTP id m1-v6so23554307plb.13 for ; Tue, 27 Nov 2018 03:47:18 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id h66sor4387458plb.46.2018.11.27.03.47.17 for (Google Transport Security); Tue, 27 Nov 2018 03:47:17 -0800 (PST) Subject: Re: [PATCH 3/3] s390/mm: fix mis-accounting of pgtable_bytes References: <1539621759-5967-1-git-send-email-schwidefsky@de.ibm.com> <1539621759-5967-4-git-send-email-schwidefsky@de.ibm.com> <20181031073149.55ddc085@mschwideX1> <20181031100944.GA3546@osiris> <20181031103623.6ykzsjdenrpeth7x@kshutemo-mobl1> <20181127073411.GA3625@osiris> From: Guenter Roeck Message-ID: Date: Tue, 27 Nov 2018 03:47:13 -0800 MIME-Version: 1.0 In-Reply-To: <20181127073411.GA3625@osiris> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Heiko Carstens , "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Li Wang , Janosch Frank , linux-kernel , Linux-MM , Martin Schwidefsky 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); > >