Messages in this thread | | | From | Dmitry Vyukov <> | Date | Thu, 19 Nov 2020 15:05:36 +0100 | Subject | Re: [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...
| |