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;
MIME-Version: 1.0
References: <1595640639-9310-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
 <384ce711-25c5-553b-8d22-965847132fbd@i-love.sakura.ne.jp>
 <0eb519fa-e77b-b655-724a-4e9eecc64626@i-love.sakura.ne.jp>
 <6933e938-f219-5e13-aee6-fe4de87eb43e@i-love.sakura.ne.jp>
 <81ab0ffd-6e80-c96c-053a-b1b4fe8694c1@i-love.sakura.ne.jp>
 <20201118142357.GW3121392@hirez.programming.kicks-ass.net>
 <1778f2e5-0a0c-2c6e-2c83-fe51d938e8a2@i-love.sakura.ne.jp>
 <20201118151038.GX3121392@hirez.programming.kicks-ass.net>
 <9bc4e07d-2a58-077b-b4c7-ab056ba33cf1@i-love.sakura.ne.jp>
 <CACT4Y+ZJNkssAQLuwfcKPTTKLZhHRAo0POGOMVsGFGizoHaNMg@mail.gmail.com>
 <CACT4Y+Zh10241gchu6e_=LwxPSEzXT-0HSmhnTtkXFZevKi_yQ@mail.gmail.com>
 <CACT4Y+a8TjV+Pe6mwne777RV+xB+aHT6GxuMLAVBn5mtK4P0Lw@mail.gmail.com>
 <CACT4Y+ZSsKjvojD8iFVFv9F5X5BvZR8vLyaKrgxUxyknma04Sg@mail.gmail.com> <5e8342c4-702f-80a9-e669-8a7386ce0da1@i-love.sakura.ne.jp>
In-Reply-To: <5e8342c4-702f-80a9-e669-8a7386ce0da1@i-love.sakura.ne.jp>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Thu, 19 Nov 2020 15:05:36 +0100
Message-ID: <CACT4Y+a4X4MNkWsvRySokKE=gO8AH1kegtUQk9T0M37EfWtN-w@mail.gmail.com>
Subject: Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     syzkaller <syzkaller@googlegroups.com>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Nov 19, 2020 at 2:45 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2020/11/19 22:06, Dmitry Vyukov wrote:
> >>>>
> >>>> I am trying to reproduce this locally first. syzbot caims it can
> >>>> reproduce it with a number of very simpler reproducers (like spawn
> >>>> process, unshare, create socket):
> >>>> https://syzkaller.appspot.com/bug?id=8a18efe79140782a88dcd098808d6ab20ed740cc
> >>>>
> >>>> I see a very slow drift, but it's very slow, so get only to:
> >>>>  direct dependencies:                 22072 [max: 32768]
> >>>>
> >>>> But that's running a very uniform workload.
> >>>>
> >>>> However when I tried to cat /proc/lockdep to see if there is anything
> >>>> fishy already,
> >>>> I got this (on c2e7554e1b85935d962127efa3c2a76483b0b3b6).
> >>>>
> >>>> Some missing locks?
>
> Not a TOMOYO's bug. Maybe a lockdep's bug.
>
> >
> > But I don't know if it's enough to explain the overflow or not...
> >
>
> Since you can't hit the limit locally, I guess we need to ask syzbot to
> run massive testcases.

I am trying to test the code that will do this. Otherwise we will get
days-long round-trips for stupid bugs. These files are also quite
huge, I afraid that may not fit into storage.

So far I get to at most:

 lock-classes:                         2901 [max: 8192]
 direct dependencies:                 25574 [max: 32768]
 dependency chains:                   40605 [max: 65536]
 dependency chain hlocks used:       176814 [max: 327680]
 stack-trace entries:                258590 [max: 524288]

with these worst offenders:

# egrep "BD: [0-9]" /proc/lockdep
00000000df5b6792 FD:    2 BD: 1235 -.-.: &obj_hash[i].lock
000000005dfeb73c FD:    1 BD: 1236 ..-.: pool_lock
00000000b86254b1 FD:   14 BD: 1111 -.-.: &rq->lock
00000000866efb75 FD:    1 BD: 1112 ....: &cfs_b->lock
000000006970cf1a FD:    2 BD: 1126 ----: tk_core.seq.seqcount
00000000f49d95b0 FD:    3 BD: 1180 -.-.: &base->lock
00000000ba3f8454 FD:    5 BD: 1115 -.-.: hrtimer_bases.lock
00000000fb340f16 FD:   16 BD: 1030 -.-.: &p->pi_lock
00000000c9f6f58c FD:    1 BD: 1114 -.-.: &per_cpu_ptr(group->pcpu, cpu)->seq
0000000049d3998c FD:    1 BD: 1112 -.-.: &cfs_rq->removed.lock
00000000fdf7f396 FD:    7 BD: 1112 -...: &rt_b->rt_runtime_lock
0000000021aedb8d FD:    1 BD: 1113 -...: &rt_rq->rt_runtime_lock
000000004e34c8d4 FD:    1 BD: 1112 ....: &cp->lock
00000000b2ac5d96 FD:    1 BD: 1127 -.-.: pvclock_gtod_data
00000000c5df4dc3 FD:    1 BD: 1031 ..-.: &tsk->delays->lock
00000000fe623698 FD:    1 BD: 1112 -...:
per_cpu_ptr(&cgroup_rstat_cpu_lock, cpu)


But the kernel continues to crash on different unrelated bugs...