On Mon, 1 Apr 2019 12:35:11 +0200 Paolo Valente wrote: > > > > Il giorno 1 apr 2019, alle ore 11:22, Dmitrii Tcvetkov > > ha scritto: > > > > On Mon, 1 Apr 2019 11:01:27 +0200 > > Paolo Valente wrote: > >> Ok, thank you. Could you please do a > >> > >> list *(bfq_bfqq_expire+0x1f3) > >> > >> for me? > >> > >> Thanks, > >> Paolo > >> > >>> > >>> > > > > Reading symbols from vmlinux...done. > > (gdb) list *(bfq_bfqq_expire+0x1f3) > > 0xffffffff813d02c3 is in bfq_bfqq_expire (block/bfq-iosched.c:3390). > > 3385 * even in case bfqq and thus parent entities go on > > receiving 3386 * service with the same budget. > > 3387 */ > > 3388 entity = entity->parent; > > 3389 for_each_entity(entity) > > 3390 entity->service = 0; > > 3391 } > > 3392 > > 3393 /* > > 3394 * Budget timeout is not implemented through a dedicated > > timer, but > > Thank you very much. Unfortunately this doesn't ring any bell. I'm > trying to reproduce the failure. It will probably take a little > time. If I don't make it, I'll ask you to kindly retry after applying > some instrumentation patch. > I looked at what git is doing just before panic and it's doing a lot of lstat() syscalls on working tree. I've attached a python script which reproduces the crash in about 10 seconds after it prepares testdir, git checkout origin/linux-5.0.y reproduces it in about 2 seconds. I have to use multiprocessing Pool as I couldn't reproduce the crash using ThreadPool, probably due to Python GIL.