linux-kernel - Re: [LKP] Re: [mm/debug] fa6726c1e7: kernel_BUG_at

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]

Message-ID: <20200429181550.GF10651@gaia>
Date:   Wed, 29 Apr 2020 19:15:51 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     "Chen, Rong A" <rong.a.chen@...el.com>
Cc:     Anshuman Khandual <anshuman.khandual@....com>,
        Qian Cai <cai@....pw>,
        Christophe Leroy <christophe.leroy@....fr>,
        kernel test robot <lkp@...el.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Ingo Molnar <mingo@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Vineet Gupta <vgupta@...opsys.com>,
        Will Deacon <will@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org
Subject: Re: [LKP] Re: [mm/debug] fa6726c1e7: kernel_BUG_at_include/linux/mm.h

On Wed, Apr 29, 2020 at 08:52:25PM +0800, Chen, Rong A wrote:
> On 4/29/2020 11:28 AM, Anshuman Khandual wrote:
> > On 04/28/2020 02:51 PM, Catalin Marinas wrote:
> > > On Tue, Apr 28, 2020 at 04:41:11AM -0400, Qian Cai wrote:
> > > > On Apr 28, 2020, at 1:54 AM, Anshuman Khandual <Anshuman.Khandual@....com> wrote:
> > > > > That is true. There is a slight change in the rules, making it explicit yes
> > > > > only when both ARCH_HAS_DEBUG_VM_PGTABLE and DEBUG_VM are enabled.
> > > > > 
> > > > > +config DEBUG_VM_PGTABLE
> > > > > +    bool "Debug arch page table for semantics compliance"
> > > > > +    depends on MMU
> > > > > +    depends on !IA64 && !ARM
> > > > > +    depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
> > > > > +    default y if ARCH_HAS_DEBUG_VM_PGTABLE && DEBUG_VM
> > > > > +    help
> > > > > 
> > > > > The default is really irrelevant as the config option can be set explicitly.
> > > > That could also explain. Since not long time ago, it was only “default
> > > > y if DEBUG_VM”, that caused the robot saved a .config with
> > > > DEBUG_VM_PGTABLE=y by default.
> > > > 
> > > > Even though you changed the rule recently, it has no effect as the
> > > > robot could “make oldconfig” from the saved config for each linux-next
> > > > tree execution and the breakage will go on.
> > > I'm not entirely sure that's the case. This report still points at the
> > > old commit fa6726c1e7 which has:
> > > 
> > > +       depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
> > > +       default n if !ARCH_HAS_DEBUG_VM_PGTABLE
> > > +       default y if DEBUG_VM
> > > 
> > > In -next we now have commit 647d9a0de34c and subsequently modified by
> > > commit 0a8646638865. So hopefully with the latest -next tree we won't
> > > see this report.
> > Could some one from LKP test framework, please confirm if this still causes
> > above problem on the latest linux-next by default ?
> 
> The .config is a rand config, the problem is still exist if run "make
> oldconfig" for the config with commit 0a8646638865.

Is randconfig expected to boot? I don't think it is but I guess it
should not trigger a BUG_ON during boot.

> $ grep -e CONFIG_MMU= -e CONFIG_EXPERT= -e CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=
> -e CONFIG_DEBUG_VM= .config
> CONFIG_EXPERT=y
> CONFIG_MMU=y
> CONFIG_DEBUG_VM=y
> 
> should we disable DEBUG_VM_PGTABLE by default?

If that's the only case where this fails in LKP, I'd rather remove the
EXPERT dependency so that it cannot be enabled. Architectures that want
to experiment with this feature will have to select
ARCH_HAS_DEBUG_VM_PGTABLE explicitly.

-- 
Catalin