linux-kernel - Re: Bisected GFP in bfq_bfqq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Apr 2019 22:22:57 +0300
From:   Dmitrii Tcvetkov <demfloro@...floro.ru>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>,
        linux-block <linux-block@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: Bisected GFP in bfq_bfqq_expire on v5.1-rc1

On Mon, 1 Apr 2019 12:35:11 +0200
Paolo Valente <paolo.valente@...aro.org> wrote:

> 
> 
> > Il giorno 1 apr 2019, alle ore 11:22, Dmitrii Tcvetkov
> > <demfloro@...floro.ru> ha scritto:
> > 
> > On Mon, 1 Apr 2019 11:01:27 +0200
> > Paolo Valente <paolo.valente@...aro.org> wrote:
> >> Ok, thank you. Could you please do a
> >> 
> >> list *(bfq_bfqq_expire+0x1f3)
> >> 
> >> for me?
> >> 
> >> Thanks,
> >> Paolo
> >> 
> >>> 
> >>> <gpf.txt><gpf-w-bfq-group-iosched.txt><config.txt>
> > 
> > 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.


View attachment "crash.py" of type "text/plain" (1556 bytes)