linux-kernel - Re: BUG: MAX_LOCKDEP

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: <CACT4Y+YFmSmXjs5EMNRPvsR-mLYeAYKypBppYq_M_boTi8a9uQ@mail.gmail.com>
Date:   Fri, 28 Sep 2018 09:56:23 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     syzbot <syzbot+aaa6fa4949cc5d9b7b25@...kaller.appspotmail.com>,
        Ingo Molnar <mingo@...nel.org>,
        Will Deacon <will.deacon@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low!

On Fri, Sep 28, 2018 at 9:00 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>> > Hello,
>> >
>> > syzbot found the following crash on:
>> >
>> > HEAD commit:    c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of git://gi..
>> > git tree:       upstream
>> > console output: https://syzkaller.appspot.com/x/log.txt?x=13810df1400000
>> > kernel config:  https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
>> > dashboard link: https://syzkaller.appspot.com/bug?extid=aaa6fa4949cc5d9b7b25
>> > compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> >
>> > Unfortunately, I don't have any reproducer for this crash yet.
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+aaa6fa4949cc5d9b7b25@...kaller.appspotmail.com
>>
>> +LOCKDEP maintainers,
>>
>> What does this BUG mean? And how should it be fixed?
>>
>> Thanks
>>
>> > BUG: MAX_LOCKDEP_CHAINS too low!
>
> Is the his result of endlessly loading and unloading modules?
>
> In which case, the fix is: don't do that then.

No modules involved, we don't have any modules in the image. Must be
something else.
Perhaps syzkaller just produced a workload so diverse that nobody ever produced.