lkml.org 
[lkml]   [2020]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3] lockdep: Allow tuning tracing capacity constants.
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...

\
 
 \ /
  Last update: 2020-11-19 15:09    [W:0.106 / U:1.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site