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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <444b9424-f1e1-2587-6d46-9848478d51e2@arm.com>
Date:   Thu, 30 Apr 2020 08:08:39 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Christophe Leroy <christophe.leroy@....fr>,
        Catalin Marinas <catalin.marinas@....com>,
        "Chen, Rong A" <rong.a.chen@...el.com>
Cc:     Qian Cai <cai@....pw>, 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 04/30/2020 12:04 AM, Christophe Leroy wrote:
> 
> 
> Le 29/04/2020 à 20:15, Catalin Marinas a écrit :
>> 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.
>>

Dropping the EXPERT dependency here seems like the best solution even
though I have always tried to avoid that (many times).

> 
> But when something is not selectable, people won't even know it exists

We will probably revisit this option later but for now it is really not
an absolute necessity for the test.

> 
> Why not try and fix the problems reported by the robots instead ?
Enabling all non-enabled platforms will be an ongoing process that will
require support and collaboration from their respective platforms folks.
Similar collaborative approach earlier had enabled successfully test run
on arc, s390, ppc32, ppc64 platforms after starting with just arm64 and
x86.