Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v4 (resend)] lockdep: Allow tuning tracing capacity
 constants.
To:     Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Dmitry Vyukov <dvyukov@google.com>
References: <20210120101044.9106-1-penguin-kernel@I-love.SAKURA.ne.jp>
 <CACT4Y+YUQj_G1o3eWFVeL2jsvdayQ0HkYkeVRuSzxOT5Xiu9mw@mail.gmail.com>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <d1bc6d20-4150-0d64-824e-6d469a8a422e@i-love.sakura.ne.jp>
Date:   Mon, 1 Feb 2021 22:24:14 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <CACT4Y+YUQj_G1o3eWFVeL2jsvdayQ0HkYkeVRuSzxOT5Xiu9mw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hello, Andrew and Linus.

We are stuck because Peter cannot respond.
I think it is time to send this patch to linux-next. What do you think?

On 2021/01/20 19:18, Dmitry Vyukov wrote:
> On Wed, Jan 20, 2021 at 11:12 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> Since syzkaller continues various test cases until the kernel crashes,
>> syzkaller tends to examine more locking dependencies than normal systems.
>> As a result, syzbot is reporting that the fuzz testing was terminated
>> due to hitting upper limits lockdep can track [1] [2] [3].
>>
>> Peter Zijlstra does not want to allow tuning these limits via kernel
>> config options, for such change discourages thinking. But analysis via
>> /proc/lockdep* did not show any obvious culprit [4] [5]. It is possible
>> that many hundreds of kn->active lock instances are to some degree
>> contributing to these problems, but there is no means to verify whether
>> these instances are created for protecting same callback functions.
>> Unless Peter provides a way to make these instances per "which callback
>> functions the lock instance will call (identified by something like MD5
>> of string representations of callback functions which each lock instance
>> will protect)" than plain "serial number", I don't think that we can
>> verify the culprit.
>>
>> [1] https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b
>> [2] https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
>> [3] https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29f
>> [4] https://lkml.kernel.org/r/4b8f7a57-fa20-47bd-48a0-ae35d860f233@i-love.sakura.ne.jp
>> [5] https://lkml.kernel.org/r/1c351187-253b-2d49-acaf-4563c63ae7d2@i-love.sakura.ne.jp
>>
>> Reported-by: syzbot <syzbot+cd0ec5211ac07c18c049@syzkaller.appspotmail.com>
>> Reported-by: syzbot <syzbot+91fd909b6e62ebe06131@syzkaller.appspotmail.com>
>> Reported-by: syzbot <syzbot+62ebe501c1ce9a91f68c@syzkaller.appspotmail.com>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> 
> Thanks for your persistence!
> I still support this. And assessment of lockdep stats on overflow
> seems to confirm it's just a very large lock graph triggered by
> syzkaller.
>